Wilco Dijkstra writes:
> Richard Sandiford wrote:
>
>>> This has probably been reported elsewhere already but I can't find
>>> such a report, so sorry for possible duplicate,
>>> but this patch is causing ICEs on aarch64
>>> FAIL: gcc.target/aarch64/sve/reduc_1.c -march=armv8.2-a+sve
>>> (inter
Richard Sandiford wrote:
>> This has probably been reported elsewhere already but I can't find
>> such a report, so sorry for possible duplicate,
>> but this patch is causing ICEs on aarch64
>> FAIL: gcc.target/aarch64/sve/reduc_1.c -march=armv8.2-a+sve
>> (internal compiler error)
>> FAIL:
Christophe Lyon writes:
> On 29 May 2018 at 19:34, Wilco Dijkstra wrote:
>> James Greenhalgh wrote:
>>
>>> > Add a missing ? to aarch64_get_lane to fix a failure in the testsuite.
>>>
>>> > I'd prefer more detail than this for a workaround; which test, why did it
>>> > start to fail, why is this
On 29 May 2018 at 19:34, Wilco Dijkstra wrote:
> James Greenhalgh wrote:
>
>> > Add a missing ? to aarch64_get_lane to fix a failure in the testsuite.
>>
>> > I'd prefer more detail than this for a workaround; which test, why did it
>> > start to fail, why is this the right solution, etc.
>
> It w
Wilco Dijkstra writes:
> Richard Sandiford
>> The "?" change seems to make intrinsic sense given the extra cost of the
>> GPR alternative. But I think the real reason for this failure is that
>> we define no V1DF patterns, and target-independent code falls back to
>> using moves in the correspon
Richard Sandiford
> The "?" change seems to make intrinsic sense given the extra cost of the
> GPR alternative. But I think the real reason for this failure is that
> we define no V1DF patterns, and target-independent code falls back to
> using moves in the corresponding *integer* mode. So for
Wilco Dijkstra writes:
> James Greenhalgh wrote:
>
>> > Add a missing ? to aarch64_get_lane to fix a failure in the testsuite.
>>
>> > I'd prefer more detail than this for a workaround; which test, why did it
>> > start to fail, why is this the right solution, etc.
>
> It was gcc.target/aarch64/ve
James Greenhalgh wrote:
> > Add a missing ? to aarch64_get_lane to fix a failure in the testsuite.
>
> > I'd prefer more detail than this for a workaround; which test, why did it
> > start to fail, why is this the right solution, etc.
It was gcc.target/aarch64/vect_copy_lane_1.c generating:
test
Richard Sandiford wrote:
> Conceptually what we're saying here is that if the given classes
> include both GENERAL_REGS and FP_REGS, we'll choose between them
> based on the mode of the register. And that makes sense for any
> class that includes both GENERAL_REGS and FP_REGS. We could write
> i
Wilco Dijkstra writes:
> Richard Sandiford wrote:
>> - if (allocno_class != ALL_REGS)
>> + if (allocno_class != POINTER_AND_FP_REGS)
>> return allocno_class;
>>
>> - if (best_class != ALL_REGS)
>> + if (best_class != POINTER_AND_FP_REGS)
>> return best_class;
>>
>> mode = PSEU
Richard Sandiford wrote:
> - if (allocno_class != ALL_REGS)
> + if (allocno_class != POINTER_AND_FP_REGS)
> return allocno_class;
>
> - if (best_class != ALL_REGS)
> + if (best_class != POINTER_AND_FP_REGS)
> return best_class;
>
> mode = PSEUDO_REGNO_MODE (regno);
> I think
Wilco Dijkstra writes:
> A recent commit removing '*' from the md files caused a large regression
> in h264ref.
> It turns out aarch64_ira_change_pseudo_allocno_class is no longer
> effective after the
> SVE changes, and the combination results in the regression. This patch
> fixes it by
> using
12 matches
Mail list logo
