[LLVMdev] [RFC] Remat Enhancements
David A. Greene
dag at cray.com
Fri Feb 24 09:48:50 PST 2012
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,
>> The change requires that live interval analysis be able to determine
>> whether and instruction is a load and whether an instruction writes to
> 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
>> 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.
More information about the llvm-dev