On Fri, Jan 30, 2015 at 10:33:06AM +0100, Jakub Jelinek wrote: > On Fri, Jan 30, 2015 at 10:12:35AM +0100, Richard Biener wrote: > > Ok - without digging into why the above would fail with your patch > > (don't see that - the use in the function call can't be &opdd) - let's > > take a step back and decide whether we want to allow user-created > > function descriptors. And if we do that if we should rather expose > > this in a more sensible way to GCC, like with using a (target) builtin. > > Say, force you to do > > > > int (*f) (int) = __builtin_fdesc (opd.fd_func, opd.fd_toc, opd.fd_aux); > > return f (3); > > > > which would allow GCC to even optimize the call to a direct one > > if it (or the target) can fold reads from the __builtin_fdesc argument > > to a function decl. Similar builtins could allow you to inspect > > a function descriptor. That way the actual memory operations > > would be hidden from the middle-end. > > That would be my preference too. Constructing the calls this way is so rare > that pessimizing 99.9% of code out there that doesn't ever need this is > IMHO undesirable.
I had a look at what it would take to fix the const function testcase, and rapidly came to the conclusion that it is not something I should attempt. I'd need at least a week, probably more, to be confident of making a proper fix. Right now, I see FUD in comments and read Fear Uncertainty and Doubt, rather than Function Use-Def chains. ;-) Besides, I hear your comments about pessimizing code. The exercise also made me view the patch I submitted as a half-baked hack. :-( Well, maybe not quite that bad, but enough to have misgivings about applying the patch. I suspect that future changes to tree optimization passes will break glibc again (at least, versions of glibc that don't have the asm fix), so it's probably better to not apply an incomplete fix. We're in a really grey area of the C standard when it comes to the glibc code. -- Alan Modra Australia Development Lab, IBM
