This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH]: Improved handling of COND_EXPR in middle-end passes


Hello,

> I'm starting to wonder if it wouldn't be better to disallow
> 
> 	lval = COND_EXPR
> 
> in GIMPLE.  Passes that benefit from this (if-conversion for the 
> vectorizer) could temporarily break this rule to get extended BBs.
> 
> But I'm not convinced either way.  Not allowing COND_EXPRs on the RHS of 
> an assignment would certainly make life more difficult for these passes.
> 
> 
> Thoughts?

there certainly are cases where one of the representations is easier to
handle than the other one.  In some situations, lval = COND_EXPR however
expresses more precisely the intent, and it also consumes less memory
than expanding it to equivalent cfg representation.  I would be in favor
of keeping this construction allowed, unless there are some significant
problems with it.

Zdenek


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]