On Thu, Jan 30, 2020 at 05:14:08PM +0100, Jakub Jelinek wrote:
> On Wed, Jan 22, 2020 at 03:24:54PM +0100, Jakub Jelinek wrote:
> > > It looks like your patch will pessimise code in some cases as well, btw?
> >
> > No, it will solely turn previous wrong-codes into something that works
> > (== cases where gen_addr3_insn would previously fail).
> > The 1)+2) variant could even improve code, as gen_addr3_insn could succeed
> > even if we currently don't call it (perhaps generate more than one insn,
> > but it still might be better than forcing the constant into register and
> > then performing add that way).
>
> Here is what I meant as the alternative, i.e. don't check any predicates,
> just gen_add3_insn, if that fails, force rs into register and retry.
> And, add REG_FRAME_RELATED_EXPR note always when we haven't emitted a single
> insn that has rtl exactly matching what we'd add the REG_FRAME_RELATED_EXPR
> with (in that case, dwarf2cfi.c is able to figure it out by itself, no need
> to waste compile time memory).
>
> Ok for trunk if it passes bootstrap/regtest?
Successfully bootstrapped/regtested on powerpc64{,le}-linux.
> 2020-01-30 Jakub Jelinek <[email protected]>
>
> PR target/93122
> * config/rs6000/rs6000-logue.c
> (rs6000_emit_probe_stack_range_stack_clash): Always use gen_add3_insn,
> if it fails, move rs into end_addr and retry. Add
> REG_FRAME_RELATED_EXPR note whenever it returns more than one insn or
> the insn pattern doesn't describe well what exactly happens to
> dwarf2cfi.c.
>
> * gcc.target/powerpc/pr93122.c: New test.
Jakub
