similar to: [LLVMdev] Whole program compile/link

On Sun, Jul 26, 2009 at 5:25 AM, Richard Pennington<rich at pennware.com> wrote: > Hi, > > I have a little conundrum. I want to bitcode link a whole program, but > I've run into a roadblock. During code generation on a processor that > doesn't support e.g. floating point, a floating point mul is turned into > a function call. This isn't known at bitcode linking

I am designing an application to run a fishing tournament I am hosting. Each fish entered will be given a point total based on the length of the fish and the species of fish. Each species has a point multiplier. For Example Trout have a multiplier of 10 so a 20 inch Trout would have a score of 200. My conundrum is in where and when do I calculate the points. The options I have come up

I'm trying to implement *MUL_LOHI for my processor. My processor has mulxss (e.g.) that gives the 32 high bits of a 64 bit multiply. I tried this in ios2ISelDAGToDAG.cpp: /// Mul/Div with two results case ISD::SMUL_LOHI: case ISD::UMUL_LOHI: { SDValue Op1 = Node->getOperand(0); SDValue Op2 = Node->getOperand(1); AddToISelQueue(Op1);

Hi, I know my last question was very vague (i.e. "It stopped working, what went wrong?"), so here is a little more concrete example: If I run the optimizer (opt) on this code snippet with -std-compile-opts the optimizer hangs. ; ModuleID = 'test.ubc' target datalayout =

On Jul 26, 2009, at 5:25 AM, Richard Pennington wrote: > I suppose that an option would be to put the support stuff in a file > that is linked in always and let the optimizer drop functions that > aren't referenced. :-( I like the idea of modeling this as a .a file, and then letting the linker figure out that there are references to the routines and have it pull them in. If your

On Sat, May 17, 2008 at 11:34 AM, Richard Pennington <rich at pennware.com> wrote: > If I run the optimizer (opt) on this code snippet with -std-compile-opts > the optimizer hangs. > > > ; ModuleID = 'test.ubc' > target datalayout = >

I thought I'd share a little bit of progress I made this weekend. I've gotten the first interesting test-case (a simple switch) through hyperblock-based DAGISel, and there's a pretty picture too! Each part of the switch is emitted directly into the DAG, rather than being deferred. This is the function: define i32 @foo(i32 %x, i32 %z) nounwind { entry: switch i32 %x,

I looked more into this. For the previously sent IR the vector width of 256 bit is found mistakenly (and reproducibly) on this hardware: model name : Intel(R) Xeon(R) CPU E5-2650 0 @ 2.00GHz For the same IR the loop vectorizer finds the correct vector width (128 bit) on: model name : Intel(R) Xeon(R) CPU E5630 @ 2.53GHz model name : Intel(R) Core(TM) i7 CPU M 640 @

The loop vectorizer is doing an amazing job so far. Most of the time. I just came across one function which led to unexpected behavior: On this function the loop vectorizer finds a 256 bit vector as the wides vector type for the x86-64 architecture. (!) This is strange, as it was always finding the correct size of 128 bit as the widest type. I isolated the IR of the function to check if this is

Hi Frank, I'm not an Intel expert, but it seems that your Xeon E5 supports AVX, which does have 256-bit vectors. The other two only supports SSE instructions, which are only 128-bit long. cheers, --renato On 10 November 2013 06:05, Frank Winter <fwinter at jlab.org> wrote: > I looked more into this. For the previously sent IR the vector width of > 256 bit is found mistakenly

Very nice! Why did you decide on hyperblock instead of SEME region and how are you forming the blocks? Evan On Apr 20, 2008, at 9:59 PM, Christopher Lamb wrote: > I thought I'd share a little bit of progress I made this weekend. > I've gotten the first interesting test-case (a simple switch) > through hyperblock-based DAGISel, and there's a pretty picture too! >

Hi Kashyap Chamarthy: thank you very much for answer my question: 一： lead to VM filesystem becoming read-only 1： test case it lead to VM filesystem becoming read-only test case as follows: we want to snapshot for VM , to obtain VM incremental data，and use virsh blockcommit，qemu-img commit，qemu-img rebase to shorten snapshot chain. Details are as follows（when VM running state， we perform the

On Tue, Jul 30, 2013 at 01:14:16PM -0600, Dan wrote: > I'll try to run through the scenario: > > > 64-bit register type target (all registers have 64 bits). > > all 32-bits are getting promoted to 64-bit integers > > Problem: > > MUL on i32 is getting promoted to MUL on i64 > > MUL on i64 is getting expanded to a library call in compiler-rt > >

I'll try to run through the scenario: 64-bit register type target (all registers have 64 bits). all 32-bits are getting promoted to 64-bit integers Problem: MUL on i32 is getting promoted to MUL on i64 MUL on i64 is getting expanded to a library call in compiler-rt the problem is that MUL32 gets promoted and then converted into a subroutine call because it is now type i64, even though

On Sat, Mar 4, 2017 at 1:19 PM, Bruce Hoult <bruce at hoult.org> wrote: > If your target does not have SHL then why don't you simply disable > converting MUL to SHL? > > MUL is converted to SHL by target independent passes when second operand is power of 2. -Vivek > > On Sat, Mar 4, 2017 at 8:22 AM, vivek pandya via llvm-dev < > llvm-dev at lists.llvm.org>

Duncan, > Hi Oleg, > >> >> /This is either a mistake, or a decision that in LLVM IR snans >> are always >> considered to be signalling. / >> Yes, this seems to be an agreement to treat "undef" as a SNaN for >> "fdiv". > > "undef" is whatever bit pattern you want it to be, i.e. the compiler > can assume it is any

Hi all, I have been looking at the way LLVM optimizes code before forwarding it to the backend I develop for my company and while building define i32 @test_extract_subreg_func(i32 %x, i32 %y) #0 { entry: %conv = zext i32 %x to i64 %conv1 = zext i32 %y to i64 %mul = mul nuw i64 %conv1, %conv %shr = lshr i64 %mul, 32 %xor = xor i64 %shr, %mul %conv2 = trunc i64 %xor to i32

Hi, All: I have a testcase which produced incorrect result, it's caused by the combination of nsw flag and ExtLdPromotion, I am leaning to say Clang set nsw flag incorrectly, but please let me know if I was wrong. Here is the reduced testcase: long long foo(int *a) { long long c; c = *a * 1405; return c; } Clang emitted the following IR (It is done by EmitMUL() in

VLIW (Very Long Instruction Word) is a long instruction format (called "group" hereafter) contains several instructions. These instructions are not dependent on each other and could be issued in a single cycle. At this moment there is no correspondent class for VLIW. MachineInstr object can only represent one instruction. Usually the number of instructions in a group is fixed. The

It seems to me that LLVM sub-register is not for the following hardware architecture. All instructions of a hardware are vector instructions. All registers contains 4 32-bit FP sub-registers. They are called r0.x, r0.y, r0.z, r0.w. Most instructions write more than one elements in this way: mul r0.xyw, r1, r2 add r0.z, r3, r4 sub r5, r0, r1 Notice that the four elements of r0 are written