search for: ptxregisterinfo

...my question is in regards to how best to implement this considering that the PTX back-end is a part of upstream LLVM and the new option will be committed to LLVM trunk. Creating a new option seems trivial for the CMake build scripts; just add a special target to automatically generate parts of the PTXRegisterInfo.td file. The Autotools build scripts seem to complicate matters, however. The makefiles for the different back-ends appear to be regular makefiles that are not processed by automake, making it difficult to introduce configure-time variables. Is the introduction of a configure-time variable in th...

...used an easy "trick" for defining an infinite register file in the backend. Does this involve defining a single dummy register, and then adding this dummy reg to each register class? Is anything more needed? I refer to the RegisterInfo.td file, as e.g: llvm-3.0.src/lib/Target/PTX/PTXRegisterInfo.td I'm (just starting) implementing an LLVM target that bares some similarities to PTX. One of these is the notion of infinite registers, since my target too is a kind of virtual/universal machine. My target will not emit object files, so there i would prefer not to define a very larget...

...arget in that the register space is "infinite" and not really typed (yes, PTX allows register types, but I do not believe that is mandatory). The infinite nature of the register space gives us a few problems: 1. We are currently constrained by the number of registers we specify in PTXRegisterInfo.td 2. The LLVM register allocators are not really solving the right problem 3. We miss opportunities for register re-use I'm sure there are more, but those are the ones I am thinking of now. To solve (1) (and (3) to some degree), I propose we get rid of register types and instead use .b...

...er space is "infinite" and not really typed (yes, PTX > allows register types, but I do not believe that is mandatory). The > infinite nature of the register space gives us a few problems: > > 1. We are currently constrained by the number of registers we specify > in PTXRegisterInfo.td > 2. The LLVM register allocators are not really solving the right > problem > 3. We miss opportunities for register re-use > > I'm sure there are more, but those are the ones I am thinking of now. > > To solve (1) (and (3) to some degree), I propose we get rid...

...nfinite" and not really typed (yes, PTX allows register types, but I do not believe that is mandatory).  The infinite nature of the register space gives us a few problems:</div> <div> <ol> <li>We are currently constrained by the number of registers we specify in PTXRegisterInfo.td</li> <li>The LLVM register allocators are not really solving the right problem</li> <li>We miss opportunities for register re-use</li> </ol> <div>I'm sure there are more, but those are the ones I am thinking of now.</div> </div...

configure:12131: $? = 0 configure:12145: result: yes configure:12157: checking tool compatibility configure:12180: error: g++|clang++|icc required but not found configure can't find a c++ compiler. On Ubuntu, please install g++ (sudo apt-get install g++). This error should have been written to your console when you ran configure. On Sun, Feb 10, 2013 at 8:35 AM, Manoj C

hello sir, i am using llvm compiler for my project.i an doing llvm installation.i followed all the steps in the llvm website but after running this command ../llvm/configure --enable-targets=host-only it executed but it didnt create any make file in build directory ,only config.log file is appeared after running this command. after running the later command it is showing like this

...y and fix every case where virtual registers won't work yet. > > Does this involve defining a single dummy register, and then adding this > dummy reg to each register class? Is anything more needed? I refer to the > RegisterInfo.td file, as e.g: llvm-3.0.src/lib/Target/PTX/** > PTXRegisterInfo.td > You can define one dummy register, or one for each register class. You only need to define the register classes that you support, and the way tablegen generates code leads to compiler warnings about empty arrays if you do not add at least one register to each register class. > > I...

That's fine with me. Unless there's a particular reason for it I would suggest perhaps changing the immediate syntax as well to swap it round, so it would be Immi32, Immi64, Immf32, etc. It doesn't bother me that much the way it currently is, but when there are lots of operations taking a register and an immediate, representing them in the same way might be a little more

Hi, Current register class naming has a confusing prefix letter 'R' (it is my bad), such as the first 'R' of RRegu32 (for unsigned 32-bit registers). I propose a 'Reg' + type name naming convention for register classes; such as: Regu16, Regu32, Regf32, Regf64 With one exception for predicate registers (capitalized first letter of 'pred'): RegPred Since