llvm dev - Oct 2010 - [LLVMdev] MachineOperand::TargetFlags question

I'm looking at utilizing the MachineOperand::TargetFlags and I'm
wondering if there is a specific reason on limiting the size of the flags to 8
bits. Also are there any assumptions on what can be validly used here that I
should keep in mind? Ideally I need 28 bits but I can code the major cases using
all 8 bits, but I don't want to clobber anything that might be used
internally in LLVM.

Thanks for any feedback,
Micah
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20101018/1f6419b9/attachment.html>

On Oct 18, 2010, at 11:59 AM, Villmow, Micah wrote:
> I’m looking at utilizing the MachineOperand::TargetFlags and I’m wondering
if there is a specific reason on limiting the size of the flags to 8 bits.
We create *LOTS* of MachineOperand instances, so it needs to be as small as
possible.
> Also are there any assumptions on what can be validly used here that I
should keep in mind? Ideally I need 28 bits but I can code the major cases using
all 8 bits, but I don’t want to clobber anything that might be used internally
in LLVM.
I think the target gets to decide what all the bits mean.

/jakob

On Oct 18, 2010, at 11:59 AM, Villmow, Micah wrote:
> I’m looking at utilizing the MachineOperand::TargetFlags and I’m wondering
if there is a specific reason on limiting the size of the flags to 8 bits. Also
are there any assumptions on what can be validly used here that I should keep in
mind? Ideally I need 28 bits but I can code the major cases using all 8 bits,
but I don’t want to clobber anything that might be used internally in LLVM.
In fact, it looks like we are losing 8 bytes to padding on hosts that align
pointers to 8 bytes. MachineOperand ought to fit in 32 bytes on 64-bit hosts.

Someone should take a look at that.

I understand that there are lots of MachineOperands created, but I need a way to
keep track of the channel that the operand utilizes within a vector register.
Since my target uses 32x4 vector registers, I need to store at least 3 bits of
information for each channel(x, y, z, w, _, 0, 1) in the fully generic case. In
the most common case I only need 2 bits(x, y, z, w) and that will fit in the
current size.

If there is a better way to do this, I'm open for suggestions. Otherwise
I'll move forward with the TargetFlags.

Micah
> -----Original Message-----
> From: Jakob Stoklund Olesen [mailto:stoklund at 2pi.dk]
> Sent: Monday, October 18, 2010 5:04 PM
> To: Villmow, Micah
> Cc: LLVM Developers Mailing List
> Subject: Re: [LLVMdev] MachineOperand::TargetFlags question
> 
> 
> On Oct 18, 2010, at 11:59 AM, Villmow, Micah wrote:
> 
> > I'm looking at utilizing the MachineOperand::TargetFlags and
I'm
> wondering if there is a specific reason on limiting the size of the
> flags to 8 bits.
> 
> We create *LOTS* of MachineOperand instances, so it needs to be as
> small as possible.
> 
> > Also are there any assumptions on what can be validly used here that
> I should keep in mind? Ideally I need 28 bits but I can code the major
> cases using all 8 bits, but I don't want to clobber anything that might
> be used internally in LLVM.
> 
> I think the target gets to decide what all the bits mean.
> 
> /jakob
>

On Oct 18, 2010, at 11:59 AM, Villmow, Micah wrote:
> I’m looking at utilizing the MachineOperand::TargetFlags and I’m wondering
if there is a specific reason on limiting the size of the flags to 8 bits. Also
are there any assumptions on what can be validly used here that I should keep in
mind? Ideally I need 28 bits but I can code the major cases using all 8 bits,
but I don’t want to clobber anything that might be used internally in LLVM.
>  
Micah, you shouldn't encode this into TargetFlags, this should become an
immediate operand of its own.

-Chris

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20101021/15e0808d/attachment.html>

From: Chris Lattner [mailto:clattner at apple.com]
Sent: Thursday, October 21, 2010 11:10 PM
To: Villmow, Micah
Cc: LLVM Developers Mailing List
Subject: Re: [LLVMdev] MachineOperand::TargetFlags question


On Oct 18, 2010, at 11:59 AM, Villmow, Micah wrote:


I'm looking at utilizing the MachineOperand::TargetFlags and I'm
wondering if there is a specific reason on limiting the size of the flags to 8
bits. Also are there any assumptions on what can be validly used here that I
should keep in mind? Ideally I need 28 bits but I can code the major cases using
all 8 bits, but I don't want to clobber anything that might be used
internally in LLVM.


Micah, you shouldn't encode this into TargetFlags, this should become an
immediate operand of its own.

-Chris

[Villmow, Micah] This is the approach I currently take, however I don't like
it because if I change an operand and it requires a change to the channel, I
have to modify a different operand instead of modifying the current operand. I
don't want to differentiate between an immediate that is an actual compile
time literal versus an immediate that is used to represent the channel swizzle.
There should be a cleaner approach where this type of check isn't required.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20101022/d79364c5/attachment.html>