On 05/19/14 00:38, Bin.Cheng wrote:
On Sat, May 17, 2014 at 12:32 AM, Jeff Law <l...@redhat.com> wrote:
On 05/16/14 04:07, Bin.Cheng wrote:
Yes, I think this one does have a good reason. The target independent
pass just makes sure that two consecutive memory access instructions
are free of data-dependency with each other, then feeds it to back-end
hook. It's back-end's responsibility to generate correct instruction.
But given these two memory access insns, there's only a couple ways they're
likely to combine into a single insn. We could just as easily have the
target independent code construct a new insn then try to recognize it. If
it's not recognized, then try the other way.
Or is it the case that we're doing something beyond upsizing the mode?
It's not about modifying an existing insn then recognize it, it's
about creating new instruction sometimes. For example, we can
generate a simple move insn in Arm mode, while have to generate a
parallel instruction in Thumb mode. Target independent part has no
idea how to generate an expected insn. Moreover, back-end may check
some special conditions too.
But can't you go through movXX to generate either the simple insn on the ARM
or the PARALLEL on the thumb?
Yes, I think it's more than upsizing the mode. There is another
example from one of x86's candidate peephole patch at
https://gcc.gnu.org/ml/gcc-patches/2014-04/msg00467.html
The patch wants to do below transformation, which I think is very
target dependent.
Presumably there's no way to go through an expander here?
The idea being that common cases where a pair moves can be turned into a
single wider move without having to write target code to make that
happen much of the time. ie 2xQI->HI, 2xHI->SI, 2xSI->DI 2xSF->DF. For
things outside those simple cases, fall back to a target hook or a
target expander.
jeff
