search for: genregisterinfo

Hi all, I cannot figure out why is named GenRegisterInfo.h.inc and not GenRegisterInfo.inc ... Is it for a dependency problem? Back again to compilation problems under win32 with VC llvm\lib\Analysis\DataStructure\Local.cpp(628) : error C2105: '--' needs l-value the line is: Result.mergeWith(getValueDest(**--CS.arg_end())); Can I submi...

On Tue, 12 Oct 2004, Paolo Invernizzi wrote: > Hi all, > I cannot figure out why is named GenRegisterInfo.h.inc and not > GenRegisterInfo.inc ... > Is it for a dependency problem? I'm not sure what you're saying here. In the X86 backend, for example, we generate both X86GenRegisterInfo.h.inc and X86GenRegisterInfo.inc. The former is #included into X86RegisterInfo.h and the latter is #i...

In r155270, I removed code from TableGen that emitted XXXRegisterClass into GenRegisterInfo.inc. This value was just a const pointer to XXXRegClass. So all places that used XXXRegisterClass should be changed to &XXXRegisterClass. I already did the conversion for all targets in the tree so this is a notice to out of tree targets. One of the most common place you might find this is set...

Hi everyone, I found some peculiar behavior of TableGen when generating [TARGET]GenRegisterInfo.inc. Some register overlaps are generated twice in this file, leading to a compilation error. I think this is because in RegisterInfoEmitter.cpp, RegisterAliases are declared as "std::map<Record*, std::set<Record*>, LessRecord>" and a requirement for std::map is that the comp...

...sterNames.inc.tmp): \ $(ObjDir)/%GenRegisterNames.inc.tmp : %.td $(ObjDir)/.dir $(Echo) "Building $(<F) register names with tblgen" - $(Verb) $(TableGen) -gen-register-enums -o $@ $< + $(Verb) $(TableGen) -gen-register-enums -o $(call SYSPATH, $@) $< $(TARGET:%=$(ObjDir)/%GenRegisterInfo.h.inc.tmp): \ $(ObjDir)/%GenRegisterInfo.h.inc.tmp : %.td $(ObjDir)/.dir $(Echo) "Building $(<F) register information header with tblgen" - $(Verb) $(TableGen) -gen-register-desc-header -o $@ $< + $(Verb) $(TableGen) -gen-register-desc-header -o $(call SYSPATH, $@) $< $(T...

On Tue, Sep 6, 2011 at 9:34 PM, Alexandru Dura <alexdura at gmail.com> wrote: > Hi everyone, > > I found some peculiar behavior of TableGen when generating > [TARGET]GenRegisterInfo.inc. Some register overlaps are generated twice in > this file, leading to a compilation error. Hi, What do you mean "overlapped register"? > I think this is because in RegisterInfoEmitter.cpp, RegisterAliases are > declared as "std::map<Record*, std::set<Record*...

...s like d0 is always 14! > I check it with ARMGenAsmMatcher.inc it was the same! > How is it possible? because it should give the same register value that > matches the underlying platform not any autogenerated value!? The returned number is the register id as defined in <YourTarget>GenRegisterInfo.inc. These numbers don't have any meaning other than to represent a particular register. The 0x01 would be the encoding used in generating the binary. The D0 has id 14 on ARM because there are 13 other registers preceding it: namespace ARM { enum { NoRegister, APSR = 1, APSR_NZCV...

Dear all, in my TestRegisterInfo.td file, I defined a register like this: class TestReg<bits<6> enc, string name> : Register<name> { let HWEncoding{5-0} = enc; let Namespace = "TEST"; } def D0 : TestReg<0x01, "d0">, DwarfRegNum<[1]>; but when I compile, the result I have in TestGenAsmMatcher.inc is this: case 'd': // 7

...be better to use metadata or some other way. Is that a reasonable expectation of the implementation? Now, onto specifics... 1. RegisterByName I couldn't find a way to get a register by name. I could teach the TableGen backend to print an additional table with a StringSwitch on <Target>GenRegisterInfo.inc and add a method getRegisterByName(char *), but that would expose a huge number of unwanted register classes which could open a huge can of worms. My idea was to be very specific and let the implementation local as <Target>RegisterInfo::getNamedRegister(char *) which will be *just* for n...

...nteger register set explicitly. I thought that aliases are transitive? > Or do I have to mention all aliases explicitly, e.g. for %d0 I need to > say [%s0,%s1,%GR0,%GR1]? Depending on how you defined the aliases, they aren't necessarily transitive. I'd like at the <yourtarget>GenRegisterInfo.inc file, and see what it lists as the aliases for each reg. > But a more interesting question is this: The scheme above assumes that > there is a "hardwired" mapping between FP registers and concerete pairs > of integer registers. In many cases this is enough, since the emul...

Reid, I think it is the first time it is run that the errors occcur !? Not sure but that would seem logical. Aaron

...hought that aliases are > transitive? > > Or do I have to mention all aliases explicitly, e.g. for %d0 I need > to > > say [%s0,%s1,%GR0,%GR1]? > > Depending on how you defined the aliases, they aren't necessarily > transitive. I'd like at the <yourtarget>GenRegisterInfo.inc file, > and see > what it lists as the aliases for each reg. Done. And I looked into the tblgen code. Tarnsitivity is not ensured by tblgen in any form, since it does not compute it. What it ensures is the commutativity of aliases, i.e. if A aliases B, then B aliases A. I think it would...

Hi, >> My target supports only f64 at the moment. >> Question: How can I tell LLVM that float is the same as double on my >> target? May be by assigning the same register class to both MVT::f32 ?> and MVT::f64? >Just don't assign a register class for the f32 type. This is what the >X86 backend does when it is in "floating point stack mode". This will

...ntion representation. This will let you define stuff like: void foo() __attribute__(((mycall))) { } You can then use a #define to hide the attribute syntax. >> Depending on how you defined the aliases, they aren't necessarily >> transitive. I'd like at the <yourtarget>GenRegisterInfo.inc file, >> and see >> what it lists as the aliases for each reg. > > Done. And I looked into the tblgen code. Tarnsitivity is not ensured by > tblgen in any form, since it does not compute it. What it ensures is > the commutativity of aliases, i.e. if A aliases B, then B a...