This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [GCC RFC]A new and simple pass merging paired load store instructions
- From: Jeff Law <law at redhat dot com>
- To: "Bin.Cheng" <amker dot cheng at gmail dot com>, Steven Bosscher <stevenb dot gcc at gmail dot com>
- Cc: "bin.cheng" <bin dot cheng at arm dot com>, GCC Patches <gcc-patches at gcc dot gnu dot org>
- Date: Fri, 16 May 2014 10:32:42 -0600
- Subject: Re: [GCC RFC]A new and simple pass merging paired load store instructions
- Authentication-results: sourceware.org; auth=none
- References: <004d01cf700e$ef1e30e0$cd5a92a0$ at arm dot com> <CABu31nMY6zapHfhr5x4BjZ3kvFuEKuhagBfx2cYbD4bbSwybTg at mail dot gmail dot com> <CAHFci2_PoNZVA15gKGDPet73UeEsay3-Ez6qKDu=E7PUVxgeiA at mail dot gmail dot com>
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?
Jeff