search for: ddunkl

On 27 May 2011 02:04, David Dunkle <ddunkle at arxan.com> wrote: > In all cases, I get code that looks pretty very the same; its like what > is below. However, I am expecting to see instruction level differences > between the vfp3 and neon versions. When I do the same with gcc 4.2 I do > see differences in the generated code....

...-----Original Message----- From: rengolin at gmail.com [mailto:rengolin at gmail.com] On Behalf Of Renato Golin Sent: Friday, May 27, 2011 2:38 AM To: David Dunkle Cc: llvmdev at cs.uiuc.edu Subject: Re: [LLVMdev] Question about ARM/vfp/NEON code generation On 27 May 2011 02:04, David Dunkle <ddunkle at arxan.com> wrote: > In all cases, I get code that looks pretty very the same; its like > what is below. However, I am expecting to see instruction level > differences between the vfp3 and neon versions. When I do the same > with gcc 4.2 I do see differences in the generated co...

I have a code generation question for ARM with VFP and NEON. I am generating code for the following function as a test: void FloatingPointTest(float f1, float f2, float f3) { float f4 = f1 * f2; if (f4 > f3) printf("%f\n",f2); else printf("%f\n",f3); } I have tried compiling with: 1. -mfloat-abi=softfp and -mfpu=neon 2.

When testing with LLVM 3.0 I noticed a crash in LLC with a test case we are running. After examining the source, I found that the crash coming from SjLjEHPrepare.cpp, specifically from "ReplaceLandingPadVal". I can explain about the crash if needed, but I will omit that for now. Testing with and LLC built from the top of trunk showed no LLC crash, and the code in SjLhEHPrepare.cpp has

...rengolin at gmail.com [mailto:rengolin at gmail.com] On Behalf Of Renato > Golin > Sent: Friday, May 27, 2011 2:38 AM > To: David Dunkle > Cc: llvmdev at cs.uiuc.edu > Subject: Re: [LLVMdev] Question about ARM/vfp/NEON code generation > > On 27 May 2011 02:04, David Dunkle <ddunkle at arxan.com> wrote: >> In all cases, I get code that looks pretty very the same; its like >> what is below. However, I am expecting to see instruction level >> differences between the vfp3 and neon versions. When I do the same >> with gcc 4.2 I do see differences in...

Hi all, LLVM CodeGen and Tools team at Apple is looking for exceptional compiler engineers. This is a great opportunity to work with many of the leaders in the LLVM community. If you are interested in this position, please send your resume / CV and relevant information to evan.cheng at apple.com Thanks, Evan Job description The Apple compiler team is seeking an engineer who is strongly

Sorry to ask about a documented use of bugpoint, but I am having trouble understanding what to do. I would like to be able to use bugpoint to simplify test cases, when the symptom is a run time difference in the testprogram behavior. That looks like what is described in the documentation as "miscompilation or perhaps code generation problems". There are examples in the LLVM doc showing

Yes, its what I want, but I can't figure out how to get bugpoint to accomplish this. -David ________________________________ From: Duncan Sands [mailto:baldrick at free.fr] Sent: Thu 2/18/2010 6:06 AM To: David Dunkle Cc: llvmdev at cs.uiuc.edu Subject: Re: [LLVMdev] using bugpoint to find miscompilation/code generation problems? Hi David, > It then iterates until a simplified test

Can anyone explain how llc translates "appending linkage" global variables like llvm.global_ctors into assembly? In the case I am examining, the global_ctor variables are in multiple bitcode object modules produced by the llvm compiler as arrays of pointers. As documented, the arrays seem to be combined when the different bitcode object modules are linked into one, so now there is one

Sorry, but does your reply yes mean both? -David Sent from my iPhone On Apr 12, 2011, at 5:51 PM, "Eric Christopher" <echristo at apple.com> wrote: > > On Apr 12, 2011, at 5:48 PM, David Dunkle wrote: > >> Pardon the basic question, but does this apply to clang, llvm-gcc, or >> both? > > Yes. > > -eric

Does llvm-gcc do more, less, or the same amount of function inlining as gcc? What about llvm-g++ and g++? I am specifically interested in inlining that occurs when I run with the --emit-llvm command line flag like this: llvm-gcc -c --emit-llvm foo.c thus generating bitcode. That is, I am not interested at this moment in what happens when I run the opt or llc tools on the bit code after its

Pardon the basic question, but does this apply to clang, llvm-gcc, or both? Thanks, -David -----Original Message----- From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Bill Wendling Sent: Tuesday, April 12, 2011 3:05 PM To: llvmdev List Subject: [LLVMdev] Exception Handling Problems Exception handling in LLVM is broken. It's as simple as that. We