similar to: [LLVMdev] PreSelection

On Mon, 21 Feb 2005, Jeff Cohen wrote: > I figured getelementptr exists as it does to facilitate data flow analysis, > but it does need to be broken down before instruction selection. It's not > just the missed optimization opportunities. It also introduces a huge amount > of complexity into instruction selection as they deal with its complexity. > It would also take care

> The second issue is that we need to do redundancy elimination and > hoisting on operations that are only exposed once instruction > selection is performed. Getelementptr expansion is just ONE > particular case of this, but it can happen with any instructions > (including the use of large integer (or any FP) constants on RISC > machines, addressing globals with PIC code,

On Feb 22, 2005, at 9:09 AM, Vikram S. Adve wrote: >> The only way to make preselection or lowermultidimrefs work is to >> duplication all of the knowledge of how the instruction selector will >> select the code (e.g. the advice about allowing constant indices to >> be grouped together). > > This is why you need a separate, low-level optimization framework - >

Vikram S. Adve wrote: >> The only way to make preselection or lowermultidimrefs work is to >> duplication all of the knowledge of how the instruction selector will >> select the code (e.g. the advice about allowing constant indices to >> be grouped together). > > > This is why you need a separate, low-level optimization framework - > the kind you were

FYI for those working with audit and intrusion detection on FreeBSD. Robert N M Watson ---------- Forwarded message ---------- Date: Mon, 5 Jun 2006 17:01:04 +0100 (BST) From: Robert Watson <rwatson@FreeBSD.org> To: current@FreeBSD.org Cc: trustedbsd-audit@TrustedBSD.org Subject: Heads up: OpenBSM 1.0a6, per-auditpipe preselection imported to CVS This is a heads up to current@ users

On Tue, 22 Feb 2005, Vikram S. Adve wrote: >> The second issue is that we need to do redundancy elimination and hoisting >> on operations that are only exposed once instruction selection is >> performed. Getelementptr expansion is just ONE particular case of this, >> but it can happen with any instructions (including the use of large integer >> (or any FP)

PreSelection.cpp uses the form "++(ConstantExpr*)->op_begin()" in a couple of places: gcc2 considers this to be an illegal use of a constant reference (the temporary iterator) as an lvalue. Fix is to use "(ConstantExpr*)->op_begin() + 1" instead. -- Casey Carter Casey at Carter.net ccarter at uiuc.edu AIM: cartec69 -------------- next part -------------- An

I figured getelementptr exists as it does to facilitate data flow analysis, but it does need to be broken down before instruction selection. It's not just the missed optimization opportunities. It also introduces a huge amount of complexity into instruction selection as they deal with its complexity. It would also take care of many of the FIXMEs in LoopStrengthReduce. Vikram Adve

> > Now the problem is obvious.  A two dimensional array access is being > performed by a single instruction.  The arithmetic needed to address > the element is implicit, and therefore inaccessible to optimizations.  > The redundant calculations can not be eliminated, nor can strength > reduction be performed.  getelementptr needs to be broken down into > its constituent

On Thu, Jul 08, 2004 at 11:12:58AM -0500, Vikram Adve wrote: > PHI nodes within machine code were originally used by the Sparc > back-end but they turned out not to be necessary. Actually, they are currently used in non-SparcV9 backends (see below). > Instead, LLVM phis are lowered to copy instructions in the machine > code (I believe this happens just after instruction selection).

PHI nodes within machine code were originally used by the Sparc back-end but they turned out not to be necessary. Instead, LLVM phis are lowered to copy instructions in the machine code (I believe this happens just after instruction selection). As far as I know, the machine PHI nodes are not used by the x86 back-end and you shouldn't need them if you insert the right copies. --Vikram

Dear 6-STABLE users, In the next 2-3 weeks, I plan to MFC support for CAPP security eventing auditing from 7-CURRENT to 6-STABLE. The implementation has been running quite nicely in -CURRENT for several months. Right now, I'm just waiting on a confirmation from Sun regarding formal allocation of a BSM header version number so as to avoid accidental version number conflicts in the

Dear 6-STABLE users, In the next 2-3 weeks, I plan to MFC support for CAPP security eventing auditing from 7-CURRENT to 6-STABLE. The implementation has been running quite nicely in -CURRENT for several months. Right now, I'm just waiting on a confirmation from Sun regarding formal allocation of a BSM header version number so as to avoid accidental version number conflicts in the

Could anybody quickly explain why PHI nodes instructions are necessary in machine code? And why the code in LiveVariables.cpp which looks at those PHI nodes (line 249 and below) is necessary. The reason I'm asking is that I try to support 64-bit comparison and I do it by generating code like: // if high1 cond high2: goto operand0 // if high1 reverse_cond high2:

I remember reading in a previous thread by Chris that all instructions will have the "instruction to insert before" as an argument to their constructors. In the code I have, this hasn't been done for the AllocaInst. I did a recent "cvsupdate", but the code still hadn't changed. Has this code already been updated ? If not, I request that it be updated as soon as

By request, I've renamed lib/CodeGen/PreSelection to lib/CodeGen/PreOpts (admittedly this was my choice :-), and the corresponding archive from preselect to preopt. If you see linker errors saying preselect.o is not found, this is the reason. This shouldn't happen if you update your entire tree at once. --Vikram

Hello, git bisect helped me today in tracking down a regression in LLVM/Clang. Because LLVM/Clang code is split across multiple git repositories, there were a few obstacles to overcome prior to using git bisect. I thought I would share them here, in the hope that they're useful for others. The main difficulty was to check out the version of clang and compiler-rt that would compile with a

I did a utils/cvsupdate, and there are no conflicts. srcdir != objdir. This is on persephone. Are you not getting this error? Perhaps I should check out a fresh tree and try to compile it? Rob On Apr 7, 2006, at 11:40 AM, Chris Lattner wrote: > On Fri, 7 Apr 2006, Robert L. Bocchino Jr. wrote: >> I just updated from CVS, and after doing a clean rebuild I get >> this

SVA looks very promising. It would be great to be able to run unmodified C safely! However, it does not seem to address my original question: how can I ensure that code cannot DoS either the memory subsystem, or the CPU? In my proposal, I could execute said code in a concurrent process with a memory quota. How would SVA address that problem? Sandro On 6/2/07, Vikram S. Adve <vadve at

Charles Steinkuehler wrote: > Dan Phillips wrote: > >> What we are left with is a requirement in abcde to overcome this and > >> until then we have the manual method. Have you any thoughts on the best > >> way to overcome this problem apart from the hacked toc3cue (do you have > >> a copy of this?) > > I do not have a copy of toc3cue...I made my own