[LLVMdev] Early-clobber constraint in TableGen

[David Greene]

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
> expressible. 

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
example.

> > 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.

Yep.

> 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.  :)

                                  -Dave