similar to: Inline asm clobber registers name

On 4 October 2016 at 19:50, Krzysztof Parzyszek via llvm-dev <llvm-dev at lists.llvm.org> wrote: > If there are no objections, I'd like to start working on this soon... > > For the AMDGPU target this implies that RC->getSize will no longer be > available in the MC layer. Another advantage of this work that hasn't been mentioned yet is it will reduce the number of uses

All, The following IR is causing the assert: \begin{ll} ; ModuleID = 'x.bc' target datalayout = "e-p:64:64:64-i1:8:8-i8:8:8-i16:16:16-i32:32:32- i64:32:64-f32:32:32-f64:64:64-v64:64:64-v128:128:128-a0:0:64- f80:128:128" target triple = "ia64-portbld-freebsd8.0" define void @__ia64_set_fast_math() nounwind { entry: tail call void asm sideeffect "mov.m

[correction] On May 20, 2008, at 1:45 PM, Marcel Moolenaar wrote: > All, > > The following IR is causing the assert: > > \begin{ll} > ; ModuleID = 'x.bc' > target datalayout = "e-p:64:64:64-i1:8:8-i8:8:8-i16:16:16-i32:32:32- > i64:32:64-f32:32:32-f64:64:64-v64:64:64-v128:128:128-a0:0:64- > f80:128:128" > target triple =

Hi, I have a set of new registers for x86 which I defined in X86RegisterInfo.td to be: def POI0: X86Reg<"poi0", 0>; def POI1: X86Reg<"poi1", 1>; def POI2: X86Reg<"poi2", 2>; def POI3: X86Reg<"poi3", 3>; def POI4: X86Reg<"poi4", 4>; def POI5: X86Reg<"poi5", 5>; def POI6: X86Reg<"poi6",

On Tue, 20 May 2008, Marcel Moolenaar wrote: > On May 20, 2008, at 1:45 PM, Marcel Moolenaar wrote: >> The following IR is causing the assert: The issue here is that the IA64 backend doesn't have inline asm support yet. This should be pretty easy to add. Take a look at the X86 version: X86TargetLowering::getRegForInlineAsmConstraint it just maps "r" onto the GPR

Hello, I m working towards backend. Here i need to define vector load and stores for 64 i32 elements. so in x86instrinfo.td i wrote; def VMOV_256B_RM : I<0x6F, MRMSrcMem, (outs VR2048:$dst), (ins i32mem:$src), "vmov_256B_rm\t{$src, $dst|$dst, $src}", [(set VR2048:$dst, (v64i32 (scalar_to_vector (loadi32 addr:$src))))],

On May 24, 2008, at 11:43 AM, Marcel Moolenaar wrote: > All, > > So far I've tried LLVM on amd64, i386, ia64 and powerpc under FreeBSD > and aside for ia64, things look pretty good for a first try. There > are 2 unexpected failures for PowerPC, which appear to be caused by > uninitialized memory. I'm still working on a fix for that (need to > brush up on my C++

All, So far I've tried LLVM on amd64, i386, ia64 and powerpc under FreeBSD and aside for ia64, things look pretty good for a first try. There are 2 unexpected failures for PowerPC, which appear to be caused by uninitialized memory. I'm still working on a fix for that (need to brush up on my C++ skills). [sidenote: In FreeBSD -current, the memory allocator initializes memory with 0xa5

On May 24, 2008, at 12:12 PM, Bill Wendling wrote: > Let us know if you would like extra eyes on the two PPC failures. Many > of us have a lot of experience with C++. :-) Do you know where these > allocations are? I don't mind if people help out, so here's some information: FAIL: /nfs/llvm/src/llvm/test/Transforms/PredicateSimplifier/ 2006-11-04-ReplacingZeros.ll Failed with

Looks good. + unsigned temp; + if (is64bit) + temp = RegInfo.createVirtualRegister(&PPC::GPRCRegClass); + else + temp = RegInfo.createVirtualRegister(&PPC::G8RCRegClass); How about? const TargetRegisterClass *RC = is64Bit ? &PPC:GPRCRegClass : &PPC:G8RCRegClass; unsigned TmpReg = RegInfo.createVirtualRegister(RC); Evan On Jul 9, 2008, at 9:16 AM, Gary

Evan Cheng wrote: > How about? > > const TargetRegisterClass *RC = is64Bit ? &PPC:GPRCRegClass : > &PPC:G8RCRegClass; > unsigned TmpReg = RegInfo.createVirtualRegister(RC); I tried something like that yesterday: const TargetRegisterClass *RC = is64bit ? &PPC::GPRCRegClass : &PPC::G8RCRegClass; but I kept getting this error no matter how I arranged it:

On 9/28/2016 7:30 PM, Quentin Colombet wrote: > Out of curiosity, could describe why this is useful to have such precision in the liveness tracking? RDF is meant to allow optimizations across the whole function. As a result, registers may change between basic blocks, and there is code to recalculate it. Accuracy is required to avoid unnecessary block live-ins. For example, calculate live-ins

Ah, didn't see that, that's what comes of trying to do something at 5pm :) I attached an updated patch which creates a virtual register instead of using R0. How does this look? Cheers, Gary Dan Gohman wrote: > PPCTargetLowering::EmitInstrWithCustomInserter has a reference > to the current MachineFunction for other purposes. Can you use > MachineFunction::getRegInfo instead?

I have posted a patch that switches the API to one that supports this (yet non-existent functionality) earlier: https://reviews.llvm.org/D24631 The comments from that were incorporated into the following RFC. Motivation: Certain targets feature "variable-sized" registers, i.e. a situation where the register size can be configured by a hardware switch. A common instruction set

Just cast both values to const TargetRegisterClass*. Evan On Jul 10, 2008, at 7:36 AM, Gary Benson wrote: > Evan Cheng wrote: >> How about? >> >> const TargetRegisterClass *RC = is64Bit ? &PPC:GPRCRegClass : >> &PPC:G8RCRegClass; >> unsigned TmpReg = RegInfo.createVirtualRegister(RC); > > I tried something like that yesterday: > > const

Hi, I am seeing a case, in a private port, of an inline asm with indirect memory references being allocated invalid registers (i.e. registers that cannot be used on loads). For example, the inline asm constraint is correct: call void asm sideeffect "MOV $$r0, $0\0AMOV $$r0, $1\0A", "*m,*m,~{r0}"(i16* @a, i16* %b) #1, !srcloc !1 but then $0 and $1 are allocated to registers

Vivek, I apologize if you took my original email as a request for implementation, I meant to be asking what is already available, I think the answer to that is the ‘preserves_most’ and ‘preserves_all’ attributes, but I will also Use ‘regmask’ if those prove to be too sub-optimal. I am still interested in figuring out the necessary and sufficient conditions For LLC to do optimal IPRA

I am hoping that someone can offer advice on a somewhat unusual issue that I am facing with the SDAG. Namely, I am trying to implement some custom operations that do very specific things on multiple registers at a time. The operations themselves will simply be intrinsics since there are no equivalent operations in IR/SDAG. However, handling the types seems rather tricky. One approach I tried is

Cool, that worked. New patch attached... Cheers, Gary Evan Cheng wrote: > Just cast both values to const TargetRegisterClass*. > > Evan > > On Jul 10, 2008, at 7:36 AM, Gary Benson wrote: > > Evan Cheng wrote: > > > How about? > > > > > > const TargetRegisterClass *RC = is64Bit ? &PPC:GPRCRegClass : > > > &PPC:G8RCRegClass; >

Hi Gary, This does not patch cleanly for me (PPCISelLowering.cpp). Can you prepare a updated patch? Thanks, Evan On Jul 10, 2008, at 11:45 AM, Gary Benson wrote: > Cool, that worked. New patch attached... > > Cheers, > Gary > > Evan Cheng wrote: >> Just cast both values to const TargetRegisterClass*. >> >> Evan >> >> On Jul 10, 2008, at 7:36