https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49330
--- Comment #17 from rguenther at suse dot de <rguenther at suse dot de> --- On Mon, 4 Jun 2018, amonakov at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49330 > > Alexander Monakov <amonakov at gcc dot gnu.org> changed: > > What |Removed |Added > ---------------------------------------------------------------------------- > CC| |amonakov at gcc dot gnu.org > > --- Comment #16 from Alexander Monakov <amonakov at gcc dot gnu.org> --- > What do you think about the suggestion made in the most recent duplicate, > namely expanding GIMPLE pointer-to-integer casts to non-transparent RTL > assignments, i.e. going from > > val = (intptr_t) ptr; > > to > > asm ("" : "=g" (rval) : "0" (rptr)); > > Wouldn't this plug the hole in one shot instead of chasing down missing > REG_POINTERs in multiple RTL passes? I suspect such assignments are simply too common and doing this would be worse than not assuming pointer arithmetic cannot cross different objects at the RTL level. How do you for example treat an aggregate memcpy of a structure containing pointers RTL expanded to say word-wise (integer-mode!) copies and then RTL afterwards figuring out reg-reg dependence chains from that. You have to realize that you'd have to introduce those "barriers" during RTL optimization itself... in which case you're back at sth like REG_POINTER. I think it would be nice to isolate this assumption on RTL and put it behind a user-crontrollable flag. That would allow benchmarking this.
