This is the mail archive of the
mailing list for the GCC project.
Re: Using MEM_EXPR inside a call expression
Adam Nemet <email@example.com> writes:
> Richard Henderson writes:
>> On 09/01/2009 12:48 PM, Adam Nemet wrote:
>> > I see. So I guess you're saying that there is little chance to optimize the
>> > loop I had in my previous email ;(.
>> Not at the rtl level. Gimple-level loop splitting should do it though.
>> > Now suppose we split late, shouldn't we still assume that data-flow can change
>> > later. IOW, wouldn't we be required to use the literal/lituse counting that
>> > alpha does?
>> If you split post-reload, data flow isn't going to change
>> in any significant way.
>> > If yes then I guess it's still better to use MEM_EXPR. MEM_EXPR also has the
>> > benefit that it does not deem indirect calls as different when cross-jumping
>> > compares the insns. I don't know how important this is though.
>> It depends on how much benefit you get from the direct
>> branch. On alpha it's quite a bit, so we work hard to
>> make sure that we can get one, if at all possible.
> Thanks, RTH.
> Can you comment on what RTH is suggesting? Besides cross-jumping I haven't
> seen indirect PIC calls get optimized much, and it seems that splitting late
> will avoid the data-flow complications.
> I can experiment with this but it would be nice to get some early buy-in.
> BTW, I have the R_MIPS_JALR patch ready for submission but if we don't need to
> worry about data-flow changes then using MEM_EXPR is not necessary.
I guess all three would work, but TBH, I think it's too dangerous to
rely on dataflow not changing in an unwanted way. We'd also have to say
specifically what that way is, and preferably assert for it somehow.
Personally, I like the dataflow approach you said you'd taken originally.
It's the kind of thing df was designed to make easy, and we already
use df in md_reorg to implement -mr10k-cache-barrier. It should just
be a case of making sure that all definitions have the same value.
I suppose the danger of using MEM_EXPR is that (in the MIPS case)
it isn't technically correct for functions that are initially
directed at a lazy-binding stub. It probably wouldn't matter
in practice though, since there'll be no lazy-binding stub if
the address is ever used in a different way. I don't really
have any objections to using MEM_EXPR.