similar to: [LLVMdev] TableGen target description file change

Hi, I just bumped into a bug in this code. The problem was as follows: I have defined a set of registers with rather similar names including digits. The code section at RegisterInfoEmitter::run(){ ... // Process sub-register sets. runs and fills the RegisterAliases map. then, ... for (unsigned i = 0, e = Regs.size(); i != e; ++i) { RegNo[Regs[i].TheDef] = i; NumAliases +=

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

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

Hi, I have a question about implementing subword register allocation problems (see the REFERENCES in the end of this message) on LLVM. I have algorithms, but don't know the best way to implement them in LLVM. I asked similar question before: http://lists.cs.uiuc.edu/pipermail/llvmdev/2005- May/004001.html Because I still don't have a satisfying solution now, I try to elaborate it

On Jun 26, 2007, at 12:57 PM, David Greene wrote: > Evan, thanks for responding so quickly. > > On Tuesday 26 June 2007 14:11, Evan Cheng wrote: >> On Jun 26, 2007, at 11:20 AM, David A. Greene wrote: >>> 28 %AL<dead> = MOV8rr %reg1024<kill>, %EAX<imp-def> >>> MOV8rr %mreg(2)<d> %reg1024 %mreg(17)<d> >>> 32 CALL64pcrel32

On Aug 21, 2012, at 3:02 PM, Chris Lattner <clattner at apple.com> wrote: > > On Aug 21, 2012, at 2:02 PM, Jakob Stoklund Olesen <stoklund at 2pi.dk> wrote: > >> All, >> >> TableGen likes to infer the MCID::UnmodeledSideEffects flag from an instruction's pattern. When an instruction doesn't have a pattern, it is assumed to have side effects. >

On Jun 26, 2007, at 11:20 AM, David A. Greene wrote: > > 28 %AL<dead> = MOV8rr %reg1024<kill>, %EAX<imp-def> > MOV8rr %mreg(2)<d> %reg1024 %mreg(17)<d> > 32 CALL64pcrel32 <ga:printf>, %RDI<kill>, %RAX<imp-def>, %RCX<imp- > def,dead>, > %RDX<imp-def,dead>, %RSI<imp-def,dead>, %RDI<imp-def,dead>, >

+Matthias > On Mar 2, 2018, at 6:42 AM, Andrea Di Biagio <andrea.dibiagio at gmail.com> wrote: > >> Known limitations on X86 processors >> ----------------------------------- >> >> 1) Partial register updates versus full register updates. >> <snip> > > MachineOperand handles this. You just need to create the machine instrs. > >

On Aug 21, 2012, at 3:45 PM, Jakob Stoklund Olesen <stoklund at 2pi.dk> wrote: >> I don't understand what you're saying. Are you proposing that all properties (may load, store, side effects) be explicitly added to all instructions, and the pattern only be used to produce warnings? > > Yes. > > The side effect inference is worse than the load/store inference, but

On Thu, Nov 8, 2012 at 1:34 AM, Anitha Boyapati <anitha.boyapati at gmail.com>wrote: ... > > I actually have confusion in mapping the role of vex_w during > instruction selection. For the moment, lets just consider vex_w and > not memop. > > [1]. What does " def rr : FMA4<>, VEX_W" mean? As per tablegen > description, "rr" now inherits FMA4 and

Evan, thanks for responding so quickly. On Tuesday 26 June 2007 14:11, Evan Cheng wrote: > On Jun 26, 2007, at 11:20 AM, David A. Greene wrote: > > 28 %AL<dead> = MOV8rr %reg1024<kill>, %EAX<imp-def> > > MOV8rr %mreg(2)<d> %reg1024 %mreg(17)<d> > > 32 CALL64pcrel32 <ga:printf>, %RDI<kill>, %RAX<imp-def>, %RCX<imp- > >

For the x86-64 target, I tried compiling a simple hello world. I don't understand the live interval information. Here's the machine instructions as dumped by LiveIntervalAnalysis: ********** MACHINEINSTRS ********** file hello.c line 3 b: 0 FNSTCW16m <fi#0>, 1, %NOREG, 0 FNSTCW16m <fi#0> 1 %mreg(0) 0 4 MOV8mi <fi#0>, 1, %NOREG, 1, 2 MOV8mi <fi#0> 1 %mreg(0) 1 2 8

Hi, looking at the fresh CVS state I see: class Register<string n> : RegisterBase<n> { list<RegisterBase> Aliases = []; } while previously the Register class did not require any parameters. The change log is just: * Target.td: Revamp the Register class, and allow the use of the RegisterGroup class to specify aliases directly in register definitions. and I

On Sep 3, 2008, at 5:58 AM, Lang Hames wrote: > Hi LLVMers, > > I have finally sorted out licensing issues and found some time, so I'm > trying to port my PBQP register allocator to 2.4 in order to Nice! We would definitely welcome your contribution. > > contribute it (if you want it). I've run into a bug that has me > confused though. > > I'm currently

On Tue, 16 Nov 2004, Vladimir Prus wrote: > and I could not find any discussions in the archives. > > Why the change was necessary? Writing: > > def gr0 : Register<"gr0">; > def gr1 : Register<"gr1">; > def gr2 : Register<"gr2">; > def gr3 : Register<"gr3">; > def gr4 :

On 8 November 2012 11:12, Cameron McInally <cameron.mcinally at nyu.edu> wrote: > On Wed, Nov 7, 2012 at 10:52 PM, Anitha Boyapati <anitha.boyapati at gmail.com> > wrote: > ... >> >> For the multiclass "fma4s", why is "mr" not inherited from "VEX_W" and >> "MemOp4" like those of "rm" or "rr" ? >

Hi LLVMers, I have finally sorted out licensing issues and found some time, so I'm trying to port my PBQP register allocator to 2.4 in order to contribute it (if you want it). I've run into a bug that has me confused though. I'm currently failing the following assertion: llc: VirtRegMap.cpp:1733: void<unnamed>::LocalSpiller::RewriteMBB(llvm::MachineBasicBlock&,

Each of the main TableGen files for the supported targets includes include "llvm/Target/Target.td" In turn, Target.td includes include "llvm/IR/Intrinsics.td" The final lines of Instrinsics.td are include "llvm/IR/IntrinsicsPowerPC.td" include "llvm/IR/IntrinsicsX86.td" include "llvm/IR/IntrinsicsARM.td" include

I noticed with my most recent sync that there is new tablegen instructions to generate target intrinsic information. Are there any examples of a backend using target specific intrinsic without having to modify llvm core to add support for them? Thanks, Micah -------------- next part -------------- An HTML attachment was scrubbed... URL:

Hi, I've been working on a proof of concept for a new configuration language for LLVM: specifically for my needs in llvmc2, but I have tried to make it as generic as possible for use throughout LLVM if other projects would like to make use of it. It's a compiler that compiles a near-subset of Standard ML to C++, with an architecture deliberately very similar to TableGen. The code is