similar to: [LLVMdev] LLVM ERROR: Cannot select

Displaying 20 results from an estimated 600 matches similar to: "[LLVMdev] LLVM ERROR: Cannot select"

2013 May 11
2
[LLVMdev] LLVM ERROR: Cannot select
Duncan, Thanks for getting back to me. I am not sure how to find the original bitcode (and related Ada source code) that causes the truncate. This is the error message that gcc gave me when I tried to compile an Ada source file using dragonegg plugin (gcc -c -fplugin...). ZY ps, sorry for multiple emails, trying to find out how to reply to a thread in the mailing list On Sat, May 11, 2013 at
2013 May 11
0
[LLVMdev] LLVM ERROR: Cannot select
Hi ZY, On 10/05/13 22:34, Zhiyuan Ren wrote: > Hello, I am new to LLVM and doing some experiment with 3.2 on Ada code. Can > anyone help me on the following error message? a truncate from an i32 to an f32 is not valid. This caused the code generator to abort. What is the original bitcode that caused this? Ciao, Duncan. > > Thanks, > ZY > > > LLVM ERROR: Cannot select:
2013 May 11
3
[LLVMdev] LLVM ERROR: Cannot select
Duncan, here is part of the assembly around the problem area. I used gcc -S -flto to generate the .s file, llvm-as on the .s fiile will show error: invalid cast opcode for cast from 'i40' to 'float' %638 = trunc i40 %637 to float %633 = bitcast i8* %632 to float* %634 = bitcast float* %633 to i40* %635 = load i40* %634, align 1 %636 = shl i40 %635, 7 %637 = ashr i40
2013 May 11
0
[LLVMdev] LLVM ERROR: Cannot select
Hi ZY, On 11/05/13 20:37, Zhiyuan Ren wrote: > Duncan, > > Thanks for getting back to me. I am not sure how to find the original bitcode > (and related Ada source code) that causes the truncate. This is the error > message that gcc gave me when I tried to compile an Ada source file using > dragonegg plugin (gcc -c -fplugin...). use -S instead of -c and add -flto The resulting
2013 May 12
0
[LLVMdev] LLVM ERROR: Cannot select
Hi ZY, On 11/05/13 22:21, Zhiyuan Ren wrote: > Duncan, > > here is part of the assembly around the problem area. I used gcc -S -flto to > generate the .s file, llvm-as on the .s fiile will show error: invalid cast > opcode for cast from 'i40' to 'float' %638 = trunc i40 %637 to float > > %633 = bitcast i8* %632 to float* > %634 = bitcast float* %633 to
2013 May 11
0
[LLVMdev] LLVM ERROR: Cannot select
Duncan, Thanks for getting back to me. I am not sure how to find the original bitcode (and related Ada source code) that causes the truncate. This is the error message that gcc gave me when I tried to compile an Ada source file using dragonegg plugin (gcc -c -fplugin...). ZY On Sat, May 11, 2013 at 12:42 PM, Duncan Sands <baldrick at free.fr> wrote: > Hi ZY, > > > On 10/05/13
2013 May 12
2
[LLVMdev] LLVM ERROR: Cannot select
Duncan, Is there a way (switch) for embedding original source code in the generated .s file? thanks, ZY On Sun, May 12, 2013 at 4:12 AM, Duncan Sands <baldrick at free.fr> wrote: > Hi ZY, > > > On 11/05/13 22:21, Zhiyuan Ren wrote: > >> Duncan, >> >> here is part of the assembly around the problem area. I used gcc -S -flto >> to >> generate
2012 Mar 06
2
Calling FORTRAN function from R issue?
Hello, I am trying to call the BLAS Level1 function zdotc from R via a .C call like this: #include "R.h" #include "R_ext/BLAS.h" void testzdotc() { Rcomplex zx[3], zy[3], ret_val; zx[0].r = 1.0; zx[0].i = 0.0; zx[1].r = 2.0; zx[0].i = 0.0; zx[2].r = 3.0; zx[0].i = 0.0; zy[0].r = 1.0; zy[0].i = 0.0; zy[1].r = 2.0; zy[0].i = 0.0; zy[2].r = 3.0;
2013 Sep 24
1
files on bricks but not on client
Hi all - We're running a 3-node distributed volume, using gluster 3.3.1. We're seeing a rare but repeated issue, where files are written to the volume, appears to be written OK, but are not accessible via NFS or the gluster client. These files appear when we inspect the bricks directly. For example, the path in question is
2014 Oct 27
4
[LLVMdev] Problem in X86 backend
Hi, I'm having some trouble wirting an instruction in the X86 backend. I made a new intrinsic and I wrote a custom inserter for my intrinsic in the X86 backend. Everything works fine, except for one instruction that I can't find how to write. I want to add this instruction in one of my machine basic block: mov [rdi], 0 How can I achieve that with the LLVM api? I tried several
2012 Jun 13
2
[LLVMdev] Assert in live update from MI scheduler.
On Jun 13, 2012, at 1:15 PM, Sergei Larin <slarin at codeaurora.org> wrote: > Andy, > > You are probably right here – look at this – before phi elimination this code looks much more sane: > > # *** IR Dump After Live Variable Analysis ***: > # Machine code for function push: SSA > Function Live Outs: %R0 > > BB#0: derived from LLVM BB %entry >
2012 Jan 19
4
[LLVMdev] Problem with cross class joins in the RegisterCoalescer
Hi, Is it intended that in some cases it is necessary to use "-disable-cross-class-join" to be sure the resulting code is ok? I have several cases where cross class joins are carried out that makes the code turn out illegal, because the "new" register class is not allowed in all instructions where it is now used. For example, by joining %vreg4, %vreg7 and %vreg9 the
2018 Apr 23
2
pre-RA scheduling/live register analysis optimization (handle move) forcing spill of registers
Hi, I have a question related to pre-RA scheduling and spill of registers. I'm writing a backend for two operands instructions set, so FPU operations result have implicit destination. For example, the result of FMUL_A_oo is implicitly the register FA_ROUTMUL. I have defined FPUaROUTMULRegisterClass containing only FA_ROUTMUL. During the instruction lowering, in order to avoid frequent spill
2012 Jun 13
2
[LLVMdev] Assert in live update from MI scheduler.
On Jun 13, 2012, at 10:49 AM, Sergei Larin <slarin at codeaurora.org> wrote: > So if this early exit is taken: > > // SSA defs do not have output/anti dependencies. > // The current operand is a def, so we have at least one. > if (llvm::next(MRI.def_begin(Reg)) == MRI.def_end()) > return; > > we do not ever get to this point: > >
2012 Jun 13
0
[LLVMdev] Assert in live update from MI scheduler.
Ok, after a long detour I am back to where I have started. I think there is a problem at dep DAG construction. Let me try to convince you. Here is the C code we are dealing with: push () { struct xx_stack *stack, *top; for (stack = xx_stack; stack; stack = stack->next) top = stack; yy_instr = top->first; } If the loop never iterates, "top" will have
2012 Jul 05
3
[LLVMdev] MachineOperand: Subreg defines and the Undef flag
Hi Jakob, Thanks for your reply. > > The <undef> flag goes on NewMI_1 because the virtual register B isn't live > before that instruction. > > But you probably shouldn't be doing this yourself. Your NewMI code isn't in > SSA form because B has multiple definitions. Just use a REG_SEQUENCE > instruction, and let the register allocator do the transformation
2012 Jun 14
1
[LLVMdev] Assert in live update from MI scheduler.
Sergei, Absolutely right, the copy/ldriw should not be reordered. I was attempting to explain that I consider it a phi-elimination bug, not a DAG builder bug. Liveness will also have problems with this code in the long run. To avoid confusion, I filed PR13112: Phi elimination generates uninitialized vreg uses, and disabled the SSA check until its fixes in r158461. However, your C code is also
2012 Jan 19
0
[LLVMdev] Problem with cross class joins in the RegisterCoalescer
On Jan 19, 2012, at 2:16 AM, Patrik Hägglund <patrik.h.hagglund at ericsson.com> wrote: > Is it intended that in some cases it is necessary to use > "-disable-cross-class-join" to be sure the resulting code is ok? No. > I have several cases where cross class joins are carried out that makes > the code turn out illegal, because the "new" register class is
2012 Jun 13
0
[LLVMdev] Assert in live update from MI scheduler.
Andy, You are probably right here - look at this - before phi elimination this code looks much more sane: # *** IR Dump After Live Variable Analysis ***: # Machine code for function push: SSA Function Live Outs: %R0 BB#0: derived from LLVM BB %entry %vreg5<def> = IMPLICIT_DEF; IntRegs:%vreg5 %vreg4<def> = TFRI_V4 <ga:@xx_stack>; IntRegs:%vreg4
2015 Apr 16
2
[LLVMdev] Multiple connected components in live interval
Hi, I have come across a csmith generated test case that made the MachineVerifier spit out: *** Bad machine code: Multiple connected components in live interval *** Having looked at what this might mean, it seems that ConnectedVNInfoEqClasses::Classify() was called on the LI in question by the verifier, and that it returned two equivalence classes, instead of just one, which is demanded by