On 2023/8/11 23:57, Jeff Law wrote:
On 8/8/23 21:54, Lehua Ding wrote:
Hi Jeff,
> The pattern's operand 0 explicitly allows MEMs as do the constraints.
> So forcing the operand into a register just seems like it's papering
> over the real problem.
The added of force_reg code is address the problem preduced after
address the error combine.
The more restrict condtion of the pattern forbidden mem->mem pattern
which will
produced in -O0. I think the implementation forgot to do this
force_reg operation before
when doing the intrinis expansion The reason this problem isn't
exposed before is because
the reload pass will converts mem->mem to mem->reg; reg->mem based on
the constraint.
So if the core issue if mem->mem, that is a common thing to avoid.
Basically in the expander you use a force_reg and then have a test like
!(MEM_P (op0) && MEM_P (op1)) in the define_insn's condition.
But the v1 had a much more complex condition. It looks like that got
cleaned up in the v2. So I'll need to look at that one more closely.
Gentle ping V2, thanks.
> This comment doesn't make sense in conjuction with your earlier
details.
> In particular combine doesn't run at -O0, so your earlier comment that
> combine creates the problem seems inconsistent with the comment above.
As the above says, the code addresses the problem which produced
after addressing the combine problem.
But combine doesn't run at -O0. So something is inconsistent. I
certainly believe we need to avoid the mem->mem case, but that's
independent of combine and affects all optimization levels.
I think it's the comment written here that is the problem. I plan to
change it to this:
/* Since there is no intrinsic where target is a mem operand, it must
be converted to reg if it is a mem operand. */
--
Best,
Lehua
