On 03/04/2019 07:41 PM, Peter Bergner wrote:
On 3/4/19 4:24 PM, Peter Bergner wrote:
On 3/4/19 4:16 PM, Peter Bergner wrote:
Index: gcc/config/rs6000/rs6000.c
===
--- gcc/config/rs6000/rs6000.c (revision 269028)
+++ gcc/config/rs6
On 3/5/19 5:51 AM, Segher Boessenkool wrote:
> On Mon, Mar 04, 2019 at 06:41:16PM -0600, Peter Bergner wrote:
>> Like this. This bootstraps and regtests with no regressions. Do you prefer
>> this instead? If so, we'll need Vlad or Jeff or ... to approve the LRA
>> changes.
>
> Either solution i
On Mon, Mar 04, 2019 at 06:41:16PM -0600, Peter Bergner wrote:
> Like this. This bootstraps and regtests with no regressions. Do you prefer
> this instead? If so, we'll need Vlad or Jeff or ... to approve the LRA
> changes.
Either solution is fine with me, whatever the LRA experts prefer. Even
On 3/5/19 5:25 AM, Segher Boessenkool wrote:
> But, it seems you need to keep track of other things on the side for LRA?
The extra LRA info is to keep track of scratches that are not needed.
In our case, only the one alternative in movsf_from_si requires a
scratch register. The rest use an X cons
Hi Peter,
On Mon, Mar 04, 2019 at 04:16:23PM -0600, Peter Bergner wrote:
> On 3/4/19 1:27 PM, Segher Boessenkool wrote:
> >> + /* If LRA is generating a direct move from a GPR to a FPR,
> >> + then the splitter is going to need a scratch register. */
> >> + rtx insn = gen_movsf_from_s
On 3/4/19 4:24 PM, Peter Bergner wrote:
> On 3/4/19 4:16 PM, Peter Bergner wrote:
>> Index: gcc/config/rs6000/rs6000.c
>> ===
>> --- gcc/config/rs6000/rs6000.c (revision 269028)
>> +++ gcc/config/rs6000/rs6000.c (working co
On 3/4/19 4:16 PM, Peter Bergner wrote:
> Index: gcc/config/rs6000/rs6000.c
> ===
> --- gcc/config/rs6000/rs6000.c(revision 269028)
> +++ gcc/config/rs6000/rs6000.c(working copy)
> @@ -9887,7 +9887,7 @@ valid_sf_si_move
On 3/4/19 1:27 PM, Segher Boessenkool wrote:
>> + /* If LRA is generating a direct move from a GPR to a FPR,
>> + then the splitter is going to need a scratch register. */
>> + rtx insn = gen_movsf_from_si_internal (operands[0], operands[1]);
>> + XEXP (XVECEXP (insn, 0, 1), 0)
Hi Peter,
On Fri, Mar 01, 2019 at 01:33:27PM -0600, Peter Bergner wrote:
> PR88845 shows a problem where LRA spilled an input operand of an inline
> asm statement by calling our generic movsf pattern which ended up generating
> an insn we don't have a pattern for, so we ICE. The insn was:
>
>
PR88845 shows a problem where LRA spilled an input operand of an inline
asm statement by calling our generic movsf pattern which ended up generating
an insn we don't have a pattern for, so we ICE. The insn was:
(insn (set (reg:SF 125)
(subreg:SF (reg:SI 124) 0)))
The problem is th
10 matches
Mail list logo