On Tue, Nov 20, 2018 at 7:36 PM Andi Kleen <a...@firstfloor.org> wrote: > > On Tue, Nov 20, 2018 at 11:53:15AM +0100, Richard Biener wrote: > > On Fri, Nov 16, 2018 at 8:07 AM Uros Bizjak <ubiz...@gmail.com> wrote: > > > > > > On Fri, Nov 16, 2018 at 4:57 AM Andi Kleen <a...@firstfloor.org> wrote: > > > > > > > > From: Andi Kleen <a...@linux.intel.com> > > > > > > > > The earlier PTWRITE builtin definition was unnecessarily restrictive, > > > > only allowing register input to PTWRITE. The instruction actually > > > > supports memory operands too, so allow that too. > > > > > > > > gcc/: > > > > > > > > 2018-11-15 Andi Kleen <a...@linux.intel.com> > > > > > > > > * config/i386/i386.md: Allow memory operands to ptwrite. > > > > > > OK. > > > > Btw, I wonder why the ptwrite builtin is in SPECIAL_ARGS2 > > commented as /* Add all special builtins with variable number of operands. > > */? > > i think i put it in the same place as a similar builtin. AFAIK > those others don't have variable arguments either, so the comment > may be wrong?
No idea... > > > > On the GIMPLE level this builtin also has quite some (bad) effects on > > alias analysis and any related optimization (vectorization, etc.). I'll > > have > > to see where the instrumenting pass now resides. > > It's fairly late now. OK, saw that. > Any suggestions for improvements? At some point I removed the edges > like the old MPX builtins to minimize memory usage, but that was > removed during an earlier review cycle. I guess it's fine now - it will have an effect on TER, limiting its ability a bit, but otherwise the builtin only lives up to RTL expansion where it becomes the UNSPEC_VOLATILE. As said, instrumenting on RTL would be an improvement, I think HJ might be able to help with that. Richard. > -Andi
