Christian,
Thanks for your reply and the wiki entry. I did search the archives,
but evidently I didn't search for the right thing. My bad. Anyways, I
am still wondering about the other part of my question. Why aren't
there Tablegen backends specific to some architecture backends? Let me
describe a different scenario. Suppose my architecture has vector and
scalar units, and suppose I want to write a machine function pass that
takes some work from the vector units and gives it to the scalar
units, for load balancing purposes. In that pass, I need to convert
some vector instructions in to a sequence of scalar instructions. For
this, I need to know what scalar instruction to generate for a vector
instruction. For example, myInst::AddV4 should become 4 myInst::Add,
etc. I need this opcode->opcode map, that can provide me this
information for all vector instructions. One way I can think of is,
put this information along with the vector instruction description in
the .td file.
class vecInst<...,myInst s> : myInst<...> {
myInst scalarVersion=s;
}
def AddV4 : vecInst<..., Add>;
def SubV2 : vecInst<..., Sub>;
...
def ORV4 : vecInst<..., OR>;
Now, I can write a tablegen backend that can output a opcode->opcode
map, which can be used by the pass. Is this and intended use case for
Tablegen? Or, are tablegen backends supposed to be generic to all
architecture backends?
Manjunath
On Mon, Jun 8, 2009 at 1:23 AM, Christian
Sayer<Christian.Sayer at dibcom.fr> wrote:> Manjunath,
> I asked this question recently, but instead of telling you to search the
archive
> I'm going to take it as a chance to recall how to do it (because
I'll do so anyway
> and even telling tablegen to use an enum for instructions is not as trivial
to do
> as you might think : )
>
> I wrote it up in the wiki at
> http://wiki.llvm.org/HowTo:_Add_arbitrary_properties_to_instructions
>
>
> Regards,
> Christian
>
> --
> Christian SAYER
>
>
>> -----Original Message-----
>> From: llvmdev-bounces at cs.uiuc.edu
>> [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Manjunath Kudlur
>> Sent: Saturday, June 06, 2009 6:47 PM
>> To: LLVM Developers Mailing List
>> Subject: [LLVMdev] Tablegen question
>>
>> I want to add a set of "properties" to each instruction in my
>> instruction set, and want to be able to query that in my
>> machine-specific optimizations. My Insts.td file looks as follows :
>>
>> class InstProperty;
>>
>> def propX : InstProperty;
>> def propY : InstProperty;
>> def propZ : InstProperty;
>>
>> class myInst<..., list<InstProperty> props> : Instruction {
>> ...
>> ...
>> list<InstProperty> Properties=props;
>> }
>>
>> def i1 : myInst<..., [propX]>;
>> def i2 : myInst<..., [propX, propZ]>;
>> def i3 : myInst<..., []>;
>>
>> I want to add a Tablegen backend that would look for Instructions
>> derived from myInst, look for Properties field, and output a
>> opcode->bitfield map as follows:
>>
>> PropMap[myInst::i1] = propX;
>> PropMap[myInst::i2] = propX | propZ;
>> PropMap[myInst::i3] = 0;
>>
>> where propX,propY,and propZ will be defined as appropriate enums.
>> Now, I looked at the current Tablegen backends, and I didn't find
any
>> that are specific to a particular architecture backend, say, to X86 or
>> Sparc etc.. That got me wondering if I am breaking some conventions
>> and not doing things in the LLVM-way. Is what I am trying to do an
>> intended use case for Tablegen? Why aren't there Tablegen backends
>> specific to some architecture backends? I would be grateful for any
>> advice from the community.
>>
>> Manjunath
>> _______________________________________________
>> LLVM Developers mailing list
>> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>>
>
>
>
>
> --
>
> CONFIDENTIAL NOTICE: The contents of this message, including any
attachments, are confidential and are intended solely for the use of the person
or entity to whom the message was addressed. If you are not the intended
recipient of this message, please be advised that any dissemination,
distribution, or use of the contents of this message is strictly prohibited. If
you received this message in error, please notify the sender. Please also
permanently delete all copies of the original message and any attached
documentation. Thank you.
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>