This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: How can I determine a register is referred through MEM at split2 stage?
On Wed, Dec 17, 2008 at 7:14 AM, Ian Lance Taylor <iant@google.com> wrote:
> "Guo, Xuepeng" <xuepeng.guo@intel.com> writes:
>
>> Thanks for your comments. It's not exactly the entire basic
>> block. It should be from the current RTL to the end of the current
>> basic block. As you know GCC will optimize "addl %ebx, %eax" to
>> "leal (%ebx, %eax), %eax" to avoid the flag register dependency
>> through a splitter in i386.md at split2 stage. But for my target, if
>> the destination register of ADD actually holds non-address operand,
>> which means "%eax" won't be used in MEM of the following RTL, this
>> optimization will incur two cycles penalty. So I need to check
>> whether the destination of ADD holds an address operands to decide
>> whether split ADD to LEA.
>
> I gather that you are using basic block as a proxy for the next use of
> the register, as the next use could presumably be after a branch
> statement.
>
> You could probably get many uses very simply by checking the
> REG_POINTER flag. It's not 100% reliable, but it's normally set on a
> register which is used as a pointer.
We tried it and it doesn't work well due to
1) REG_POINTER(x) is documented as nonzero if a register x holds a
pointer and stored
in the frame-related filed. That may be accurate now.
2) Our LEA optimization happened at the stage of split2 after the
IRA stage. The register x is
a hard register and can hold anything it can hold. What we concern
here is whether what register
x holds will be used as an address soon and if it so we will use LEA,
otherwise we will use ADD.
In another word we can't judge register x holds a pointer only by
REG_POINTER because there
is no function to update this information step by step.
> Otherwise you could use the dataflow framework to find the uses of the
> register, but that may be too expensive since you can't easily control
> the whole pass.
>
> Otherwise you will indeed have to write your own walker. This is easy
> to write using for_each_rtx.
>
We will try that.
Thanks.
--
H.J.