similar to: [LLVMdev] Thoughts about the llvm architecture

>> Hi! >> >> The following thoughts about the llvm architecture I'd like to share >> with you >> (from the perspective of a user): >> >> - If a backend has no vector support, then I wonder why there is no >> de-vectorization >> pass that operates on indermediate llvm-ir. I would think that if you >> use such a target >> then

On Jul 29, 2010, at 5:24 AM, Jochen Wilhelmy wrote: > Hi! > > The following thoughts about the llvm architecture I'd like to share > with you > (from the perspective of a user): > > - If a backend has no vector support, then I wonder why there is no > de-vectorization > pass that operates on indermediate llvm-ir. I would think that if you > use such a target

On 2010-09-03 13:19, Jochen Wilhelmy wrote: > >>> Hi! >>> >>> The following thoughts about the llvm architecture I'd like to share >>> with you >>> (from the perspective of a user): >>> >>> - If a backend has no vector support, then I wonder why there is no >>> de-vectorization >>> pass that operates on

>>>> Hi! >>>> >>>> The following thoughts about the llvm architecture I'd like to share >>>> with you >>>> (from the perspective of a user): >>>> >>>> - If a backend has no vector support, then I wonder why there is no >>>> de-vectorization >>>> pass that operates on indermediate

Jochen Wilhelmy schrieb: >>>>> Hi! >>>>> >>>>> The following thoughts about the llvm architecture I'd like to share >>>>> with you >>>>> (from the perspective of a user): >>>>> >>>>> - If a backend has no vector support, then I wonder why there is no >>>>> de-vectorization

Am 29.12.2011 19:52, schrieb Reid Kleckner: > I think Chris is saying that the and is necessary because with your i1 > trunc you're ignoring all of the high bits. The and implements that. > If you don't want this behavior, don't generate the trunc in the > first place and just compare the full width to zero. But if a backend sees trunc from i8 to i1 it should know

>> Hi! >> >> before InstCombine (llvm::createInstructionCombiningPass()) I have >> a trunc from i8 to i1 and then a select: >> >> %45 = load i8* @myGlobal, align 1 >> %tobool = trunc i8 %45 to i1 >> %cond = select i1 %tobool, float 1.000000e+00, float -1.000000e+00 >> >> after instCombine I have: >> >> %29 = load i8*

> > Currently we don't do any unsafe-math opts in InstCombine. Not sure > if this is policy or if it's just that nobody's implemented it. > perhaps in can be implemented using the existing flag -enable-unsafe-fp-math. what do you think? -Jochen

I think Chris is saying that the and is necessary because with your i1 trunc you're ignoring all of the high bits. The and implements that. If you don't want this behavior, don't generate the trunc in the first place and just compare the full width to zero. Reid On Wed, Dec 28, 2011 at 6:45 AM, Jochen Wilhelmy <j.wilhelmy at arcor.de>wrote: > > >> Hi! >

Hi! Is there a pass that optimizes vector operations? If I have for examle a sequence of shufflevector instructions that optimizes them? (in opencl notation e.g. a.xyzw.wzyx.xxxx -> a.wwww) -Jochen

Hi! before InstCombine (llvm::createInstructionCombiningPass()) I have a trunc from i8 to i1 and then a select: %45 = load i8* @myGlobal, align 1 %tobool = trunc i8 %45 to i1 %cond = select i1 %tobool, float 1.000000e+00, float -1.000000e+00 after instCombine I have: %29 = load i8* @myGlobal, align 1 %30 = and i8 %29, 1 %tobool = icmp ne i8 %30, 0 %cond = select i1 %tobool, float 1.000000e+00,

Hello all, I would like to propose a large change to LLVM that I would be happy to implement. The instruction selection legalizer knows of three different ways to legalize an action (ignoring an already legal action). - Expansion - Promotion - Custom Expanding a node will lead to one of two things - the operation will be split into several equivalent smaller operations (i.e. 64-bit

Hi Vikram, I think it's worth continuing to discuss this on-list. I'm interested in different kinds of embedded software, but specifically in TinyOS applications. > We (more accurately, John Criswell and Brice Lin) are working on a > debugging version of SAFECode right now, which should be robust enough > to play with soon. This is great to hear. I know the SAFECode paper

> You should check out the -enable-finite-only-fp-math and -enable-unsafe-fp-math options. Good hint, but llvm::UnsafeFPMath = true; llvm::FiniteOnlyFPMathOption = true; at the beginning of my code does not help. I found llvm::Reassociate::OptimizeExpression in llvm\lib\Transforms\Scalar\Reassociate.cpp which looks like it does X * 0 = 0 for int, but it does not get called for

John, We (more accurately, John Criswell and Brice Lin) are working on a debugging version of SAFECode right now, which should be robust enough to play with soon. What kinds of embedded codes do you have in mind? One of our goals has been to minimize or even eliminate run-time checks for embedded code that meets certain restrictions. You can see the following paper for more details:

> By the way i8 and trunc come from clang as clang represents a bool as i8  > in memory. of course it would > be a nice feature if I could tell clang to always use i1 for bool, this > would also remove the problem. > Is this possible? > > -Jochen #include <stdbool.h> ?

> > The DAGCombiner appears to do both of these with -enable-unsafe-fp-math . > But isn't the DAGCombiner a part of the back-end? Is it possible to get llvm ir out of the DAGCombiner? Do you mean the SelectionDAG? I further process llvm ir and therefore need a "best possible" optimization on llvm ir. -Jochen

SVA/safecode looks interesting. Is it available to play with? I grepped for strings such as "sva" "secure" "safecode" in the LLVM source tree and didn't find anything, nor did I see obvious links to implementations from the project web pages. In the short term, questions I'd be interested in answering are: What happens when embedded codes that I care

Hello, I am interested to use Speex but need to know If I can use it under our project's constraint. We need to use a low cost micro controller on a very small PCB. This means there's no space for an external DSP unit. Can someone tell me if using an AVR32 (Atmel uc) which has a floating point calculation unit and DSP instruction set and running at ~50Mhz for a narrow band

On Jul 26, 2010, at 2:52 PMPDT, Jochen Wilhelmy wrote: >> Currently we don't do any unsafe-math opts in InstCombine. Not >> sure if this is policy or if it's just that nobody's implemented it. >> > perhaps in can be implemented using the existing flag -enable-unsafe- > fp-math. > what do you think? I don't see any good reason these opts shouldn't