similar to: [LLVMdev] Question about ExpandPostRAPseudos.cpp

Hi Eli, Thanks, I’ll look into that then! Cheers, Taddeüs From: Friedman, Eli Sent: Wednesday, 2 August 2017 19:48 To: Taddeus; llvm-dev at lists.llvm.org Subject: Re: [llvm-dev] Efficiently ignoring upper 32 pointer bits whendereferencing On 8/2/2017 9:03 AM, Taddeus via llvm-dev wrote: > Hi all, > > I am experiencing a problem with the representation of addresses in > the x86_64

Hi all, I am experiencing a problem with the representation of addresses in the x86_64 TableGen backend and was hoping someone can tell me if it is fixable. Any comments or hints in to send me in the right direction would be greatly appreciated. I am using LLVM version 3.8, commit 251286. I have an IR pass that stores metadata in the upper 32 bits of 64-bit pointers in order to implement

Hi guys, I’m trying to figure out a way to assign initial values to function arguments. For a function in IR: define i32 @main (i32 %0, i32 %1) { %tmp = add i32 %0, %1 ... } I would like to make sure %0 has some initial value (e.g. i32 0) under some circumstances. Is there any easy way to do this? I understand that %0 comes from a live-in value which is defined from outside of the function. I

I ran into an interesting problem when helping to land a scheduler .td file that my colleague had written. The problem that came up was that a multiply/add pair was not combined into an madd, but just for our CPU. Upon digging into it, the problem turned out to be that '(instregex "^SUB" ...' was matching "SUBREG_TO_REG" and incorrectly increasing the schedule length.

Hi, I'm still having problems implementing my custom inserter in the X86 backend. I found a solution to my last problem (http://lists.cs.uiuc.edu/pipermail/llvmdev/2014-October/078296.html), by using a virtual register. The binary works when it's compiled in -O0, but not in -O1,-O2,... I really can't figure what I'm doing wrong... Any idea? Here is the code of my custom

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- > >

We have a function that has 256 loads and 256 fmuladds. This block of operations is bounded at either end by an OpenCL barrier (an AMDIL fence instruction). The loads and multiply/adds are ordinarily interleaved... that is, the IR going in to code generation looks like: %39 = load float addrspace(3)* getelementptr inbounds ([16 x [17 x float]] addrspace(3)* @sgemm.b, i32 0, i32 0, i32 0), align

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 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&,

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 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>, >

On Tuesday 26 June 2007 14:57, David Greene wrote: > > EAX and its sub-registers are defined by the MOV8rr instruction > > > > implicitly: > > > 28 %AL<dead> = MOV8rr %reg1024<kill>, %EAX<imp-def> > > > MOV8rr %mreg(2)<d> %reg1024 %mreg(17)<d> > > > > So their live ranges start at 28+2. > > Yep, this makes sense

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

I'm trying to fix a bug in the PowerPC SPE backend that prevents a bunch of FreeBSD ports from building, including gtk20. The attached file, generated from the following C source, triggers the "Def == PreviousDef" assertion in isNopCopy(): typedef float a; typedef struct { a b, c; } complex; d(complex *e, complex *h) { double f = h->c, g = h->b; i(g); e->c = g *

Some time ago I saw a report of strange single-stepping behavior given Swift code that looks like this: 1| var input = [16, 14, 10, 9, 8, 7, 4, 3, 2, 1] //< Only number 1 is relevant. 2| print("start") TL;DR: The debugger steps from line 2 -> 1 -> 2 in this code example. One clean way to fix this bug is to remove debug locations from ConstantSDNodes, and I'm asking if

+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. > >

Just noticed that when we generate a custom lowering for some atomics that we forgot to transfer the MemOperand to the new instruction that touches memory. -- Mon Ping Index: lib/Target/X86/X86ISelLowering.cpp =================================================================== --- lib/Target/X86/X86ISelLowering.cpp (revision 53702) +++ lib/Target/X86/X86ISelLowering.cpp (working copy) @@

Hi, I am working on a new back-end for LLVM. This architecture has two register types, data(A) and accumulator(B). A registers are i32 where as B registers are i64. This is causing me some headaches, as far as I can tell, it's not really possible to mix the two using tablegen? In the hardware, every instruction can either take an A register or a B register, in tablegen (as far as I can

Dear LLVM guys, I am getting an error with my pass implementation, and I cannot figure it out. Basically, I've implemented part of a register allocation algorithm, but I am having problems to set the passes correctly. For instance, for this program below, the following error message is produced: .c ----------------------| .bc ---------------------------------

Tracking down a problem with one of our benchmark codes, we've discovered that some of the patterns in X86InstrX86-64.td are wrong. Specifically: def MOV64toPQIrm : RPDI<0x6E, MRMSrcMem, (outs VR128:$dst), (ins i64mem:$src), "mov{d|q}\t{$src, $dst|$dst, $src}", [(set VR128:$dst, (v2i64 (scalar_to_vector