similar to: [LLVMdev] Heads up: Local register allocator going away

Hal's advice helps me a lot to understand the implementation much better. Thanks so much! So, now I am able to state my problem more clearly: 1) There are two kinds of locals, i.e., the local variables originated from the source code (like C/C++), and the compilation generated temporaries. After instruction selection phase, the former is seen as frame indexes, while the latter is seen as

On Tue, Jun 30, 2009 at 6:11 AM, Sylvere Teissier<st at invia.fr> wrote: >> 2. The backend (llc) converts that to Dwarf (or something else as >> desired by that back-end). >> > How advanced is LLVM Dwarf generation compared to GCC ? Devang can probably give a better answer, but my understanding is: 1. At -O0, the quality is very good, with a few exceptions (like

The attached patch fixes bugs related to MachineBasicBlock::iterator. I don't have any test cases that reproduce on an X86 machine the problems that this patch fixes (these bugs were found when make check was run on a mips board). Please review. The first part just ensures that iterator I is not instr_end() before it invokes isInsideBundle(). The second part changes the signature of spillAll

Hi, Can anyone help me with the stack slot coloring optimization? This corresponding file is /lib/codegen/stackslotcoloring.cpp. It is said this optimization was for stack slot overlay for frame size reduction, after register allocation phase. And this transformation pass relies on the LiveStack analysis pass. How, when checking the source code, it seems the LiveStack analysis has not been

> Calling 0 is undefined behavior; the optimizer is within its rights to > remove this. Why do you want to call 0? For example, on embedded platforms you call 0 to do a soft reset. > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

> 2. The backend (llc) converts that to Dwarf (or something else as > desired by that back-end). > How advanced is LLVM Dwarf generation compared to GCC ?

Hi, this is a small patch of ARM Instructions description because "-verify-machineinstrs" complains about that. This doesn't break the tests on my machine. Regards -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: patch_barrier URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20090929/84aca914/attachment.ksh>

I think there is a latency problem with the mail server. That create answer echo :D > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

> How each target handles the code generation > differences will be the interesting part. Why not use a target specific calling convention? An interrupt is like a normal function call, it only has a different calling convention.

Hi All, I'm working on a full migration from windows DC to samba DC, and i'm actually having a problem with terminal server settings! I run a terminal server on win2k, but i would store all my user information on samba. Although, i don't find any documentations or info about terminal server setting with samba. Is it supposed to be possible to store it with samba and a ldap backend,

Hello, I run CentOS 5.6 on a Dell PowerEdge R815 with 256 GB of RAM. We use Sun Grid Engine to schedule jobs on this node. I want to limit the memory usage about 150 GB per process. So i use the /etc/security/limits.conf configuration file. I test this configuration with some tools with a lower GB limit (about 2 or 4 GB), and it works ! But, at least one process (oases - a bioinformatics

To say this first: This whole discussion about using virtregs until emit or having growable physregs is hard to argue without actually having experience trying to go either way. Problems when using virtregs throughout the backend until emit time: - The MC layer is using MCPhysReg (which is an uint16_t) and would need retrofitting to support virtregs - VirtRegs are assumed to have a definition,

We had some additional discussion on this. There is a lot of concern generally about post-RA passes which do not expect to have to handle virtual registers; specifically if they unexpectedly start seeing virtual registers, or if they work today but start making assumptions in the future. We discussed considering a mechanism that would require MachineFunctionPasses to "opt-in" and declare

Here are 2 patches, which are independent of each other. The first splits PrologEpilogInserter into 2 parts : http://reviews.llvm.org/D16481 After looking at the code I thought it made more sense for the major split to include whether callee-saved register spills are supported. So for non-virtual targets, virtual registers are not supported and scavenging is optionally supported, and vice versa

----- Original Message ----- > From: "Kevin B Smith" <kevin.b.smith at intel.com> > To: "Hal Finkel" <hfinkel at anl.gov> > Cc: "Krzysztof Parzyszek" <kparzysz at codeaurora.org>, llvm-dev at lists.llvm.org > Sent: Thursday, December 10, 2015 2:32:36 PM > Subject: RE: [llvm-dev] Allowing virtual registers after register allocation >

> On Jan 22, 2016, at 1:23 PM, Matthias Braun <mbraun at apple.com> wrote: > >> >> On Jan 22, 2016, at 12:29 PM, Derek Schuff <dschuff at google.com <mailto:dschuff at google.com>> wrote: >> >> Here are 2 patches, which are independent of each other. >> >> The first splits PrologEpilogInserter into 2 parts :

--- Chris Lattner <sabre at nondot.org> wrote: > On Thu, 21 Dec 2006, Roman Levenstein wrote: > > following: > > 1) some of the fixed registers intervals are merged with some > virtual > > registers intervals > > 2) later there is a need to spill one of the allocated registers, > but > > since all joined intervals are FIXED intervals now due to (1),

Hi Susan, With your bitcode file I am now able to reproduce the issue you're seeing. It looks like this is a problem with the naive rewriting from virtregs to physregs. It appears that the subreg field of physreg operands is ignored post-register allocation. In your testcase %vreg11:sub32 is being rewritten to RBX:sub32, but the :sub32 part is being quietly dropped when the assembly is

Hi Susan, > 1. I tried running the PBQP allocator (as a dynamic pass), but that didn't > work.... Can you tell from this what I'm doing wrong? > The PBQP allocator is built into the LLVM CodeGen library, so the "-regalloc=pbqp" option is already available in llc. If you've built a copy of the PBQP allocator in a separate library it will try to re-register

My tst.bc is attached. I had to use ssh to copy it from my office machine to my home laptop. In case that corrupts it, I also put a copy here: http://pages.cs.wisc.edu/~horwitz/LANG/tst.bc I created the file like this: clang -emit-llvm -O0 -c tst.c -o tst.bc opt -mem2reg tst.bc > tst.mem2reg mv tst.mem2reg tst.bc Susan On 11/4/2012 3:27 PM, Lang Hames wrote: > Hi Susan, >