Re: [PATCH][AArch64] Fix aarch64_ira_change_pseudo_allocno_class

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 >>>

Re: [PATCH][AArch64] Fix aarch64_ira_change_pseudo_allocno_class

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:   

Re: [PATCH][AArch64] Fix aarch64_ira_change_pseudo_allocno_class

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

Re: [PATCH][AArch64] Fix aarch64_ira_change_pseudo_allocno_class

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

Re: [PATCH][AArch64] Fix aarch64_ira_change_pseudo_allocno_class

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

Re: [PATCH][AArch64] Fix aarch64_ira_change_pseudo_allocno_class

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

Re: [PATCH][AArch64] Fix aarch64_ira_change_pseudo_allocno_class

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

Re: [PATCH][AArch64] Fix aarch64_ira_change_pseudo_allocno_class

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:

Re: [PATCH][AArch64] Fix aarch64_ira_change_pseudo_allocno_class

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 >

Re: [PATCH][AArch64] Fix aarch64_ira_change_pseudo_allocno_class

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

Re: [PATCH][AArch64] Fix aarch64_ira_change_pseudo_allocno_class

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

Re: [PATCH][AArch64] Fix aarch64_ira_change_pseudo_allocno_class

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