[LLVMdev] [RFC] Remat Enhancements

[David A. Greene]

Jakob Stoklund Olesen <stoklund at 2pi.dk> writes:

> That's great, but I really wish you would discuss the design of these
> things publicly, and not develop features on long-running secret
> branches. If you secretly start out in the wrong direction, you could
> be wasting a lot of your time.

I don't have a choice.  I have to get patches approved after I already
have them.  In this case, I had a week to get the feature done to meet a
deadline so there was no time for previous discussion.  I really don't
like that I'm under these constriants but that's the way it is,
unfortunately.

>> The change requires that live interval analysis be able to determine
>> whether and instruction is a load and whether an instruction writes to
>> memory.
>
> Just use MI->mayLoad(), MI->mayStore().

Does this also account for arithmetic instructions with memops?  These
interfaces didn't exist in 2.9.

> [And live interval analysis shouldn't be involved in remat these days.]

Ok, I'm working off 2.9 so I'll have to update for trunk.  That's no
problem.

>> The remat code itself identifies load instructions and checks to see
>> whether it interferes with any instructions that write to memory.
>
> How does that affect compile time?

I haven't noticed any impact.

>> Finally, are MachineMemOperands guaranteed (modulo bugs, of course) to
>> be preserved at least through regalloc?
>
> They are preserved, but they are not 'guaranteed'.  A load or store
> with missing memops should conservatively be treated as volatile,
> aliasing everything.

Right, that's what I do.  If mayLoad() and mayStore() cover all
instructions with memory semantics, it should be fine.

Thanks!

                               -Dave