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>
Jakob Stoklund Olesen
2010-Oct-19 00:03 UTC
[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
Jakob Stoklund Olesen
2010-Oct-19 00:26 UTC
[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.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>
Reasonably Related Threads
- [LLVMdev] MachineOperand::TargetFlags question
- [LLVMdev] MachineOperand::TargetFlags question
- [LLVMdev] No more TargetFlags on MO_Register MachineOperands
- [LLVMdev] No more TargetFlags on MO_Register MachineOperands
- [LLVMdev] No more TargetFlags on MO_Register MachineOperands