This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [patch 3/4] Separate gimple.[ch] and gimplify.[ch] - front end files
- From: "H.J. Lu" <hjl dot tools at gmail dot com>
- To: Andrew MacLeod <amacleod at redhat dot com>
- Cc: Michael Matz <matz at suse dot de>, Richard Biener <richard dot guenther at gmail dot com>, gcc-patches <gcc-patches at gcc dot gnu dot org>, Jeff Law <law at redhat dot com>, Diego Novillo <dnovillo at google dot com>
- Date: Thu, 14 Nov 2013 14:06:58 -0800
- Subject: Re: [patch 3/4] Separate gimple.[ch] and gimplify.[ch] - front end files
- Authentication-results: sourceware.org; auth=none
- References: <5281460E dot 1070001 at redhat dot com> <52814709 dot 6080904 at redhat dot com> <CAFiYyc3xFo3KzNv8QurvoBW-Ef9=0FdbgoC5Z=U=zACPPb90gg at mail dot gmail dot com> <528388D1 dot 7050808 at redhat dot com> <alpine dot LNX dot 2 dot 00 dot 1311141606320 dot 11100 at wotan dot suse dot de> <5284ED7A dot 8020805 at redhat dot com> <alpine dot LNX dot 2 dot 00 dot 1311141638320 dot 11100 at wotan dot suse dot de> <5284F6C0 dot 1000408 at redhat dot com> <alpine dot LNX dot 2 dot 00 dot 1311141717180 dot 11100 at wotan dot suse dot de> <5284FB9C dot 6040400 at redhat dot com>
On Thu, Nov 14, 2013 at 8:34 AM, Andrew MacLeod <amacleod@redhat.com> wrote:
> On 11/14/2013 11:23 AM, Michael Matz wrote:
>>
>> Hi,
>>
>> On Thu, 14 Nov 2013, Andrew MacLeod wrote:
>>
>>>> I think if following through with the whole plan there would (and
>>>> should) be nothing remaining that could be called a gimple expression.
>>>
>>> very possibly, i just haven't gotten to those parts yet. I can change
>>> the name back to gimple-decl.[ch] or some such thing if you like that
>>> better.
>>
>> -object? -operand? -stuff? ;-) Will all of these splits land at trunk,
>> i.e. 4.9? Why the hurry when not even such high-level things are clear?
>> I mean how can you think about rearchitecting the gimple data structures
>> without having looked at the current details. It's clear that not every
>> detail of the design can be fixated at this point, but basic questions
>> like "what's the operands?", "will there be expressions?", "how do we
>> iterate?", "recursive structures or not?" should at least get some answer
>> before really starting grind work, shouldn't they?
>>
> The splits are for header file cleanup and re-structuring into logical
> components. As I mentioned in the original post, the file is needed to
> break dependency cycles between gimple.h (the statements) , the iterators,
> and gimplification. It is for the gimple stuff which doesn't need any of
> those things but is consumed by them.
>
> This really has nothing to do with my future plans, other than the fact that
> I also said whatever is in this file is will eventually be split into more
> things, but I'm not ready to do those splits yet, thus the gimple-blah name
> doesn't matter to me. gimple-expr seemed convenient at the time but clearly
> you don't like it, and I'll happily call it whatever you want. It's a grab
> bag of all the gimple values which are still trees...
>
> maybe the suggested gimple-val.[ch] is ok?
>
> Andrew
It breaks Ada build. I checked in the following patch to unbreak
it.
--
H.J.
---
Index: ada/ChangeLog
===================================================================
--- ada/ChangeLog (revision 204825)
+++ ada/ChangeLog (working copy)
@@ -1,3 +1,7 @@
+2013-11-14 H.J. Lu <hongjiu.lu@intel.com>
+
+ * gcc-interface/trans.c: Include gimple.h and pointer-set.h.
+
2013-11-12 Andrew MacLeod <amacleod@redhat.com>
* gcc-interface/trans.c: Include gimplify.h.
Index: ada/gcc-interface/trans.c
===================================================================
--- ada/gcc-interface/trans.c (revision 204825)
+++ ada/gcc-interface/trans.c (working copy)
@@ -33,7 +33,9 @@
#include "output.h"
#include "libfuncs.h" /* For set_stack_check_libfunc. */
#include "tree-iterator.h"
+#include "gimple.h"
#include "gimplify.h"
+#include "pointer-set.h"
#include "bitmap.h"
#include "cgraph.h"
#include "diagnostic.h"