On Tue, May 03, 2005 at 08:48:20PM -0400, Ian Lance Taylor wrote:
> If I understand what you are saying, I am complaining about the
> specific cases where the difference is in the syntax.
>
Drat, trapped in my own web of logic and definitions ;) Yes,
that's exactly what I was saying and now I see the inconsistency
you were pointing out.
Hmm, I'm not quite sure how to go about this. There is another
case where we make these magic passes, COND_EXPR. In GENERIC
each arm is a BIND_EXPR, in GIMPLE each arm is just a label. I
was essentially trying to pull the same stunt.
I kind of like the idea of taking an operand code and twist its
operands slightly when we lower the IL. But then, I'm not the
kind of person you'd want in a language standards committee.
So, there would be 2 such inconsistencies with our current IL
levels: SWITCH_EXPR and COND_EXPR. What would you change?
Perhaps it could be a nice cleanup of the abstraction.
Regarding the GOMP_* codes, perhaps it would suffice to do:
GENERIC GOMP_PARALLEL <clauses, body>
GIMPLE GOMP_PARALLEL <g_clauses, GOTO_EXPR L1>
L1:
g_body
(we can then either put a GOMP_PARALLEL_END marker, or just
figure out the region using std region building techniques).
Notice that we will be very tempted to change that 'GOTO_EXPR L1'
to just 'L1'. No point emitting the GOTO_EXPR when we "know"
that is always a GOTO_EXPR in GIMPLE. That's what led to the
COND_EXPR current structure.
> This is obviously all just my opinion, as somebody who came late to
> this stuff and is trying to understand it.
>
Which is exactly the kind of POV that can usually spot
inconsistencies such as this one :)
Thanks. Diego.
