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] |
On 08/03/2015 07:02 PM, Martin Sebor wrote:
I've prototyped this approach in a couple places in the middle end. Both implementations are very simple and work great when the code isn't optimized away. The problem is that the optimizations done at various points between the front end and the final gimplification make the diagnostics inconsistent. For instance, with F being the type of the builtin, this is diagnosed in the first prototype: F* foo () { if (0) return __builtin_trap; return 0; } but this isn't: F* bar () { return 0 ? __builtin_trap : 0; } because the ternary ?: expression is folded into a constant by the front end even before it reaches the gimplifier, while the if-else statement isn't folded until the control flow graph is built. (As an aside: I'm wondering why that is. Why have the front end do any optimization at all if the middle can and does them too, and better?)
This is largely historical baggage, I think, from days where computers had less memory and we were trying to do as much processing as possible immediately.
The c++-delayed-folding branch delays folding the ?: expression until the end of the function, at which point we can see better what context the function is being used in, which could simplify your patch.
But your question leads me to wonder if we need to do front end folding there, either...
Jason
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |