Re: Extend tree-call-cdce to calls whose result is used

[Richard Sandiford <richard dot sandiford at arm dot com>]

Michael Matz <matz@suse.de> writes:
> On Sat, 7 Nov 2015, Richard Sandiford wrote:
>> For -fmath-errno, builtins.c currently expands calls to sqrt to:
>> 
>>     y = sqrt_optab (x);
>>     if (y != y)
>>       [ sqrt (x); or errno = EDOM; ]
>> 
>> - the call to sqrt is protected by the result of the optab rather
>>   than the input.  It would be better to check !(x >= 0), like
>>   tree-call-cdce.c does.
>
> It depends.  With fast-math (and hence without NaNs) you can trivially 
> optimize away a (y != y) test.  You can't do so with !(x>=0) at all.  

-ffast-math would already cause us to treat the function as not setting
errno, so the code wouldn't be used.

>> - the branch isn't exposed at the gimple level and so gets little
>>   high-level optimisation.
>> 
>> - we do this for log too, but for log a zero input produces
>>   -inf rather than a NaN, and sets errno to ERANGE rather than EDOM.
>> 
>> This patch moves the code to tree-call-cdce.c instead,
>
> This somehow feels wrong.  Dead-code elimination doesn't have anything to 
> do with the transformation you want, it rather is rewriting all feasible 
> calls into something else, like fold_builtins does.  Also cdce currently 
> doesn't seem to do any checks on the fast-math flags, so I wonder if some 
> of the conditions that you now also insert for calls whose results are 
> used stay until final code.

Isn't that just a question of what you call the current pass though?
Arguably "conditional DCE" was always a confusing name, since the
pass only _adds_ code :-)  Obviously the point is that it eliminates
the external call at runtime in most cases, but so does the transformation
I'm adding.

I'd be happy to rename the file to something else if that would help.

>> Previously the pass was only enabled by default at -O2 or above, but the 
>> old builtins.c code was enabled at -O.  The patch therefore enables the 
>> pass at -O as well.
>
> The pass is somewhat expensive in that it removes dominator info and 
> schedules a full ssa update.  The transformation is trivial enough that 
> dominators and SSA form can be updated on the fly, I think without that 
> it's not feasible for -O.

r229916 fixed that for the non-EH case.  I posted a patch to update
the vops for the non-EH case as well:

    https://gcc.gnu.org/ml/gcc-patches/2015-10/msg03355.html

If this aspect is going to be a blocker, maybe we can reconsider that,
since the EH case should be rare.

> But as said I think this transformation should better be moved into 
> builtin folding (or other call folding), at which point also the fast-math 
> flags can be checked.  The infrastructure routines of tree-call-cdce can 
> be used there of course.  If so moved the cdce pass would be subsumed by 
> that btw. (because the dead call result will be trivially exposed), and 
> that would be a good thing.

Yeah, that was why I added the code to the cdce pass.  I don't think
it makes sense to have one pass that adds range checks for calls whose
lhs is unused and a separate pass for calls whose lhs isn't used.

But by "builtin folding", do you mean fold_builtin_n etc.?
I thought the point was that we were trying to move away from
relying on folding at that level.  Or did you mean something else?

Thanks,
Richard