similar to: [LLVMdev] troubles with ISD::FPOWI

Hi - attached is a patch to enable building DragonEgg (x86_64) for LLVM3.3 and LLVM3.4. That is, add these changes to the 3.3 release, and it becomes possible to build DragonEgg against a llvm3.4 compiler. Regards, Richard Gorton Cognitive Electronics rcgorton at cog-e.com ---------- -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name:

Dan, I have a large list of functions(60+) that I want to be legalized. I have currently been adding them in the same manner as pow/exp etc... These functions come in both scalar and vector versions of up to 16 elements as the 1.0 spec requires. Is this something that I could Merge back into the tree or is another approach required? Some of the thoughts we were having as not to clutter the llvm

Hello, all. To get my feet wet and hopefully make a small contribution, I was looking for something small to start with. I settled on one of the suggestions from the CodeGen readme: > Reassociate should turn things like: > > int factorial(int X) { > return X*X*X*X*X*X*X*X; > } > > into llvm.powi calls, allowing the code generator to > produce balanced multiplication

On Apr 8, 2009, at 12:43 AM, Duncan Sands wrote: > Hi Micah, > >> There seems to be some math library functions that are already built >> into llvm as intrinsic(pow, exp, etc...) but there are lots that >> are not >> built in yet. Is there currently work going on that is implementing >> these? I do not want to duplicate work so I want to see what is out

Hey all, I am trying to implement a subtarget for the X86 architecture that only has 64 bit Registers. While running LLC on the IR for a very simple program, llc fails on an assertion that says it doesn't know how to promote ISD::FRAMEINDEX. I've tried to look for why how to promote the frameindex which is stored in a i32 variable to an i64 variable but can't seem to find where

In the following example with gcc style builtins, in once case llvm.powi.f64 is emitted and in the other just a call to library function powf. ~/llvm/build/Debug+Asserts/bin/clang -S -emit-llvm pow1.c Why is that? Is there a way to force the call to an llvm style builtin? Tia. Reed -------------- next part -------------- A non-text attachment was scrubbed... Name: pow1.c Type: text/x-csrc

Per subject, this patch adding an additional pass to handle vector operations; the idea is that this allows removing the code from LegalizeDAG that handles illegal types, which should be a significant simplification. There are still some issues with this patch, but does the approach look sane? -Eli -------------- next part -------------- Index: lib/CodeGen/SelectionDAG/LegalizeVectorOps.cpp

2015-03-11 16:22 GMT-05:00 Richard Gorton < rcgorton at cognitive-electronics.com>: > I can confirm that musl builds and works correctly with clang/llvm. We > are using musl as a libc for our architecture. > It has a much smaller code footprint than newlib or glibc. > I successfully cross-compile the must-libc using clang, with the configuration: C=clang

Inspired by the dicussion of removing IA64, I just tried running llc over test/CodeGen/Generic targeting all the legal values of -march and counting the number of crashes and aborts, as an attempt to roughly measure the maturity/bitrottedness of the backends. I went through and fixed some easy legalization issues; the following is the remaining issues: x86-64: 3. I'm not entirely sure

I'm running into a bit of trouble using virt-builder and I'm hoping that someone might be able to point in the right direction. My build process creates a custom ISO image which is subsequently used to kickstart an Oracle X4-2 server using PXE. The ISO is a minimal install and contains a suite of packages and customization scripts to properly configure our box during first boot. The

Dear, I am looking to build a compiler-assembler with a custom architecture. I have a new Instruction set defined with me and I would like atleast my C programs to get converted to assembly language corresponding to the custom architecture. I have been going through llvm and its resources on the web, Can any one of you offer guidance about the above problem. All I want is to develop a tool

> > FWIW, I build baremetal newlib for arm-eabi using clang, and it works. I >> had to patch a few of the __attribute__((naked)) functions because they >> were using pre-UAL asm syntax, but for the most part it "just works". >> > I build the baremetal newlib using arm-none-eabi-gcc as well, but after linking with the hello world program, it failed to run on

There's at least one other LLVM user which would find these useful, and probably more, so it may be appropriate to merge this into the main tree. I'm interested to hear if anyone else has an opinion here. An llvm.math namespace seems like a good idea. Instead of using "fpow" though, I'd prefer to just use names like "pow". For consistency, the ISD namespace

On Wed, May 20, 2009 at 1:19 PM, Eli Friedman <eli.friedman at gmail.com> wrote: > Per subject, this patch adding an additional pass to handle vector > operations; the idea is that this allows removing the code from > LegalizeDAG that handles illegal types, which should be a significant > simplification.  There are still some issues with this patch, but does > the approach

On Wed, May 20, 2009 at 4:55 PM, Dan Gohman <gohman at apple.com> wrote: > Can you explain why you chose the approach of using a new pass? > I pictured removing LegalizeDAG's type legalization code would > mostly consist of finding all the places that use TLI.getTypeAction > and just deleting code for handling its Expand and Promote. Are you > anticipating something more

On May 20, 2009, at 1:34 PM, Eli Friedman wrote: > On Wed, May 20, 2009 at 1:19 PM, Eli Friedman > <eli.friedman at gmail.com> wrote: > >> Per subject, this patch adding an additional pass to handle vector >> >> operations; the idea is that this allows removing the code from >> >> LegalizeDAG that handles illegal types, which should be a significant

Hi everyone, I compiled grep with llvm-3.4(because consumer tool uses llvm3.4 bit code) and generate bit-code for this. When I am running with lli output is pseudo instructions should be removed before code emission UNREACHABLE executed at /home/awanish/llvm/llvm-3.4.2/lib/Target/X86/X86CodeEmitter.cpp:1176! 0 libLLVM-3.4.so 0x00007f1250f655d5 llvm::sys::PrintStackTrace(_IO_FILE*) + 37 1

On Wed, May 20, 2009 at 5:26 PM, Eli Friedman <eli.friedman at gmail.com> wrote: > On Wed, May 20, 2009 at 4:55 PM, Dan Gohman <gohman at apple.com> wrote: >> Can you explain why you chose the approach of using a new pass? >> I pictured removing LegalizeDAG's type legalization code would >> mostly consist of finding all the places that use TLI.getTypeAction

Hi! I'm not sure how to handle intrinsic functions that have non-i32 operands. The target only supports 32-bit registers natively but for some operations, only the lower 16 bits are significant. For example, the SMULS instruction does a 16 x 16 fractional multiply with saturation. I've defined an intrinsic function: int __builtin_opus_smuls(short a, short b);

Hi, I'm using KLEE which supports only LLVM-2.9. In order to compile some c++ file which requires gcc 4.5, I built Dragonegg 2.9 with LLVM-2.9 and gcc 4.5.1 on a Linux x86_64 machine. It was sucessfully built. When I try to compile a c++ file using this plugin as below gcc test.cpp -fplugin=path/dragonegg.so I got this error: cc1plus: error: Cannot load plugin path/dragonegg.so