[LLVMdev] Early-clobber constraint in TableGen
dag at cray.com
Wed Dec 16 11:15:37 PST 2009
On Wednesday 16 December 2009 12:54, Jim Grosbach wrote:
> > That's better. Is there any way you could convince TableGen to
> > recognize
> > that 'constraints = "$success != $src", "$success != $ptr"' is
> > semantically
> > equivalent to earlyclobber? Maybe check that the common operand in
> > both
> > contraints is declared to interfere with all other operands and if
> > that's
> > so, mark it earlyclobber.
> It would be possible, yes. I'm concerned that would imply that one
> could specify a constraint that the output register couldn't overlap
> with one input register, but could with another, which isn't
Not right now, though, but I don't think it would be hard to add. I'm
not saying you should add that now, though.
> Thus my preference for specifying the constraint solely
> as an attribute of the output register rather than referencing the
> other operands explicitly.
Yep, I understand the simplicity argument.
> I'm not hugely tied to the name. I chose it because it matches the
> usage in GCC documentation for inline assembly with the same concepts
> and how the concept is expressed elsewhere in the compiler. If I'm not
> mistaken, due to the GCC nomenclature, the linux kernel also refers to
> this sort of thing as an early-clobber.
This is my own bias speaking, but gcc has some fantastically stupid names
for things. I don't necessarily see it as meritorious to follow its
> > It seems to me the root problem here is that the instruction has two
> > outputs
> > and we don't want the output to be allocated to the same register as
> > the
> > inputs. We have no way to express multiple outputs in TableGen.
> Close, but not precisely. The issue is that the values in the input
> registers may still be needed in the hardware at the instruction stage
> where the output register needs to be written, or some other such
> timing issue that if the registers are the same the hardware can't
> guarantee proper access ordering for correct behavior. From LLVM's
Right, you are of course more correct here.
> The name is trying to capture the idea that the hardware may clobber
> the value in the destination register early enough in the execution of
> the instruction that it could conflict with reading the value from the
> source register if they are the same.
> I think you're right that it's best to go ahead with this for now and
> then if a better solution is arrived at later, we can update things to
> use that.
I'm fine with that. Not that my opinion matters more than anyone else's. :)
More information about the llvm-dev