On Tue, Sep 15, 2020 at 12:46:00PM +0100, Richard Sandiford wrote: > Segher Boessenkool <seg...@kernel.crashing.org> writes: > > On Mon, Sep 14, 2020 at 05:33:33PM +0100, Richard Sandiford wrote: > >> > However, for the cases on Power as Segher mentioned, there are also some > >> > scratch registers used for > >> > Other purpose, not sure whether we can correctly generate zeroing in > >> > middle-end for Power? > >> > >> Segher would be better placed to answer that, but I think the process > >> above has to give a conservatively-accurate list of live registers. > >> If it misses a register, the other late rtl passes could clobber > >> that same register. > > > > It will zero a whole bunch of registers that are overwritten later, that > > are not parameter passing registers either. > > This thread has covered two main issues: correctness and cost. > The question above was about correctness, but your reply seems to be > about cost.
The issues are very heavily intertwined. A much too high execution cost is unacceptable, just like machine code that does not implement the source code faithfully. > On the cost issue: when you say some registers are “overwritten later”: > which registers do you mean, and who would be doing the overwriting? (Glue) code that is generated by the linker. > We were talking about inserting zeroing instructions immediately before > returns that already exist. It looks like the main Power return > pattern is: It is. > (define_insn "<return_str>return" > [(any_return)] > "<return_pred>" > "blr" > [(set_attr "type" "jmpreg")]) > > Does this overwrite anything other than the PC? If not, it doesn't (We do not have a "PC" register, but :-) ) Nope. The blr instruction does not write any register. (The base "bclr[l]" insn can write to CTR and LR). > look like anything in the function itself would clobber other registers > later (i.e. later than the inserted zeroing instructions). And of course, > if an attacker is performing a ROP attack, the attacker controls which > address the BLR returns to. That does not matter for the *normal* case. Making the normal case even more expensive than this scheme already is is no good. Anyway, I was concerned about other architectures, too (that may not even *have* a GCC port (yet)). The point is that this should follow all the rules we have for RTL. Now that it will use DF (thanks!), most of that will follow automatically (or easily, anyway). Segher
