similar to: [LLVMdev] Overriding TargetRegisterInfo::hasReservedSpillSlot

Hi all, Virtual ISAs such as WebAssembly and NVPTX use infinite virtual register sets instead of traditional phsyical registers. PrologEpilogInserter is run after register allocation and asserts that all virtuals have been allocated but doesn't otherwise depend on this if scavenging is not needed. We'd like to use the target-independent PEI code for WebAssembly, so we're proposing a

Hi Anton, Anton Korobeynikov wrote: > I don't see any huge problems with writing such pass: just create > stack frame objects at fixed offsets inside your MF pass - and you'll > done. The only problem is that you need to do this early - before > prologue / epilogue inserter code runs, since afterwards stack frame > layout is almostly finalized (at "high level")

Adding Jiangning Liu to the thread. Jiangning reported a similar issue on the llvm-commits list on Debian aarch64. In general it sounds like std::call_once may not really be bug free. Jiangning, can you please provide your gcc/libstdc++ version? Thanks, -Chris > On Nov 4, 2014, at 9:38 AM, Bill Schmidt <wschmidt at linux.vnet.ibm.com> wrote: > > On Tue, 2014-11-04 at 12:17

Ok, I'll put a patch together to fix this later today. I'll probably do what Reid was suggesting and use what is already in there for Windows. Thanks, Samuel Bill Schmidt <wschmidt at linux.vnet.ibm.com> wrote on 11/04/2014 12:11:08 PM: > From: Bill Schmidt <wschmidt at linux.vnet.ibm.com> > To: Samuel F Antao/Watson/IBM at IBMUS > Cc: azanella at

I need to use ‘createVirtualRegister’ for a specific case in my ‘eliminateFrameIndex’ function implementation. However, whenever that code is executed, I get the assertion "MachineCopyPropagation should be run after register allocation!” at a later stage. I have seen that at least a couple of backend implementations (including ARM Thumb) create virtual registers in ‘eliminatedFrameIndex’.

It seems the crash of llvm/clang build on aarch64 Debian has been fixed by r220941. Thanks, -Jiangning 2014-11-05 8:45 GMT+08:00 Jiangning Liu <liujiangning1 at gmail.com>: > The versions I'm using right now are > > * gcc: (Debian/Linaro 4.9.1-14) 4.9.1 > * libstdc++: libstdc++.so.6.0.20 > > Thanks, > -Jiangning > > 2014-11-05 4:46 GMT+08:00 Chris Bieneman

On Thu, 2013-01-31 at 11:29 -0600, Bill Schmidt wrote: > On Thu, 2013-01-31 at 11:23 -0600, Bill Schmidt wrote: > > On Thu, 2013-01-31 at 10:17 -0600, Bill Schmidt wrote: > > > > > > On Thu, 2013-01-31 at 09:42 -0600, Hal Finkel wrote: > > > > ----- Original Message ----- > > > > > From: "Bill Schmidt" <wschmidt at

Hi, Nicolas > Could you point me where those hooks are in the llvm code? I didn't find > any. Look into PrologEpilogInserter.cpp::PEI::runOnMachineFunction(). There are calls to hooks inside TargetRegisterInfo: TargetRegisterInfo::processFunctionBeforeCalleeSavedScan() and TargetRegisterInfo::processFunctionBeforeFrameFinalized(). Maybe they are not so convenient when working via JIT

On Thu, 2013-01-31 at 11:23 -0600, Bill Schmidt wrote: > On Thu, 2013-01-31 at 10:17 -0600, Bill Schmidt wrote: > > > > On Thu, 2013-01-31 at 09:42 -0600, Hal Finkel wrote: > > > ----- Original Message ----- > > > > From: "Bill Schmidt" <wschmidt at linux.vnet.ibm.com> > > > > To: llvmdev at cs.uiuc.edu > > > > Sent:

On Wed, Dec 9, 2015 at 3:02 PM Hal Finkel <hfinkel at anl.gov> wrote: > ----- Original Message ----- > > From: "Derek Schuff via llvm-dev" <llvm-dev at lists.llvm.org> > > To: llvm-dev at lists.llvm.org > > Sent: Wednesday, December 9, 2015 4:31:31 PM > > Subject: [llvm-dev] Allowing virtual registers after register allocation > > > >

----- Original Message ----- > From: "Bill Schmidt" <wschmidt at linux.vnet.ibm.com> > To: llvmdev at cs.uiuc.edu > Sent: Thursday, January 31, 2013 9:26:15 AM > Subject: [LLVMdev] Getting command line options to affect subtarget features > > The problem I'm trying to solve: Invoking clang on PowerPC with > -fno-altivec has no effect. > > From what

The problem I'm trying to solve: Invoking clang on PowerPC with -fno-altivec has no effect. >From what I've been able to piece together, PPC.td specifies various CPUs and the processor features available on each. So for example we have: def FeatureAltivec : SubtargetFeature<"altivec","HasAltivec", "true",

On Thu, 2013-01-31 at 09:42 -0600, Hal Finkel wrote: > ----- Original Message ----- > > From: "Bill Schmidt" <wschmidt at linux.vnet.ibm.com> > > To: llvmdev at cs.uiuc.edu > > Sent: Thursday, January 31, 2013 9:26:15 AM > > Subject: [LLVMdev] Getting command line options to affect subtarget features > > > > The problem I'm trying to

Hi Bill, You can find the same issue in the buildbot: http://lab.llvm.org:8011/builders/clang-ppc64-elf-linux2/builds/16444/steps/compile.llvm.stage2/logs/stdio It is failing for me both in BE (gcc 4.8.2) and LE(4.9.1). I am compiling with clang 3.5, but those are the gcc toolchains I am using. What do you think is the best way to fix this? Thanks! Samuel Bill Schmidt <wschmidt at

On Thu, 2013-01-31 at 10:17 -0600, Bill Schmidt wrote: > > On Thu, 2013-01-31 at 09:42 -0600, Hal Finkel wrote: > > ----- Original Message ----- > > > From: "Bill Schmidt" <wschmidt at linux.vnet.ibm.com> > > > To: llvmdev at cs.uiuc.edu > > > Sent: Thursday, January 31, 2013 9:26:15 AM > > > Subject: [LLVMdev] Getting command line

Dear, I have been going through the Targets registered with llvm. As I was looking around, I found an include statement in the file XXXRegisterInfo.h (XXX is any target), #include "llvm/Target/TargetRegisterInfo.h" The question is there is no folder called Target in my llvm directory (file TargetRegistorInfo.h missing ) and still programs compile in the XXX architecture. I want access

Hi, Would anyone object to my moving the TargetRegisterInfo and TargetInstrInfo classes into libCodeGen? TargetInstrInfo is already halfway there with its TargetInstrInfoImpl class implementing most shared functionality. The lib/Target/TargetInstrInfo.cpp file has two remaining functions that happen to not depend on libCodeGen, but I don't think they serve any purpose as part of libTarget.

> On Dec 9, 2015, at 4:13 PM, Quentin Colombet <qcolombet at apple.com> wrote: > > Hi, > > I would actually go the other direction, i.e., stick to physical registers but with an infinite number. > The rational is that after register allocation we broke all the nice properties of the pre-alloc virtual registers. For instance, the existing liveness algorithm cannot be used

On Nov 27, 2012, at 10:24 AM, Jakob Stoklund Olesen <stoklund at 2pi.dk> wrote: > Would anyone object to my moving the TargetRegisterInfo and TargetInstrInfo classes into libCodeGen? > > TargetInstrInfo is already halfway there with its TargetInstrInfoImpl class implementing most shared functionality. The lib/Target/TargetInstrInfo.cpp file has two remaining functions that happen

Hi all, I'm investigating the following test case that reports as an unexpected pass on powerpc64-unknown-linux-gnu. Clang : CodeGenCXX/member-alignment.cpp This test case is marked as XFAIL for arm and powerpc. However, the test passes fine for powerpc64-unknown-linux-gnu. There are two tests of this form: void t::bar(void) { // CHECK: _ZN1t3barEv{{.*}} align 2