similar to: Register spilling fix for experimental 6502 backend

Greetings, LLVM devs, For the past few weeks, I have been putting together a 6502 backend for LLVM. The 6502 and its derivatives, of course, have powered countless microcomputers, game consoles and arcade machines over the past 40 years. The backend is just an experimental hobby project right now. The code is available here: <https://github.com/beholdnec/llvm-m6502>. This branch introduces

For the little C test program where a constant is stored in memory and also used as a parameter: #include <stdint.h> uint64_t val, *p; extern uint64_t xtr( uint64_t); uint64_t caller() { uint64_t x; p = &val; x = 12345123400L; *p = x; return xtr(x); } clang (3.2, 3.3 and svn) generates the following X86 code (at -O3): caller: movq

> I expected that this optimization would be picked > up in a cse, gvn, machine-cse or even peepholing pass. > > Comments? At the LLVM IR level this is represented as define i64 @caller() #0 { entry: store i64* @val, i64** @p, align 8, !tbaa !0 store i64 12345123400, i64* @val, align 8, !tbaa !3 %call = tail call i64 @xtr(i64 12345123400) #2 ret i64 %call } Which is

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 >

On Aug 2, 2013, at 1:37 PM, Rafael Espíndola <rafael.espindola at gmail.com> wrote: >> I expected that this optimization would be picked >> up in a cse, gvn, machine-cse or even peepholing pass. >> >> Comments? > > > At the LLVM IR level this is represented as > > define i64 @caller() #0 { > entry: > store i64* @val, i64** @p, align 8, !tbaa

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

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: > >

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

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

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

Hi, I am working on a simple copy propagation pass for the R600 backend that propagates immediates rather than registers. For example, I want to transform: ... %vreg1 = V_MOV_B32 1 %vreg2 = V_ADD_I32 %vreg1, %vreg0 ... into: %vreg1 = V_MOV_B32 1 ; <- Only delete this if it is dead %vreg2 = V_ADD_I32 1, %vreg0 For best results, I am trying to run this pass after the TwoAddressInstruction

Hi, we are in the midst of an interesting work that begun with setting 'guessInstructionProperties = 0' in the SystemZ backend. We have found this to be useful, and discovered many instructions where the hasSideEffects flag was incorrectly set while it actually shouldn't. The attached patch and test case triggers an assert in TwoAddress.  (bin/llc ./tc_TwoAddr_crash.ll

I wonder if we can do this in a separate analysis MachineFunction SSA pass. 1) SelectionDAG will generate a pseudo instruction MutatingFMA. When it's generated it's allowed to have d = a * b + c form, where d doesn't have to be in {a, b, c}. 2) Later, the proposed pass uses an algorithm to decide for instruction MI: `%vreg0 = MutatingFMA %vreg1, %vreg2, %vreg3`, it should tie %vreg0

Hi, All, I'm trying to build a customized backend and I need to lower the formal arguments like this: There are several specific registers just for storing formal arguments. And also there are several general purpose registers for computation. If there is an instruction which uses parameters, I should first use a move instruction, which moves the value to general purpose register. For

Hi Vincent, On 25/10/2012 18:14, Vincent Lejeune wrote: > When examining the debug output of regalloc, it seems that joining 32bits reg also joins 128 parent reg. > > If I look at the : > %vreg34<def> = COPY %vreg6:sel_y; R600_Reg32:%vreg34 R600_Reg128:%vreg6 > > instructions ; it gets joined to : > 928B%vreg34<def> = COPY %vreg48:sel_y; > > when vreg6 and

I've inherited some target code, but there is no SELECT lowering in my target. But somewhere/somehow SELECT is being transformed into a predicated move. I've traced SELECT everywhere in Codegen/SelectionDAG. Any ideas on tracking this down to the point in Codegen lowering/dag-conversion to a predicated series? Again, I do not have a lowering rule in my target for SELECT. If I do a IR

Hi! During my backend development I get the error message for some tests: *** Bad machine code: Virtual register def doesn't dominate all uses. *** (C source-code, byte-code disassembly and printed machine code at the end of the email) The first USE of vreg4 in BB#1 has no previous DEF in BB#0 or #1. But why? I can't see how the LLVM byte-code is transformed to the lower machine code.

I am having trouble trying to enable post RA scheduler for the Mips backend. This is the bit code of the function I am compiling: (gdb) p MF.Fn->dump() define void @PointToHPoint(%struct.HPointStruct* noalias sret %agg.result, %struct.ObjPointStruct* byval %P) nounwind { entry: %res = alloca %struct.HPointStruct, align 8 %x2 = bitcast %struct.ObjPointStruct* %P to double* %0 = load

On Sep 18, 2012, at 1:45 PM, Bjorn De Sutter <bjorn.desutter at elis.ugent.be> wrote: > I am working on a backend for a CGRA architecture with advanced predicate support (as on EPIC machines and as first used in the OpenIMPACT compiler). Until last month, the backend was working fine, but since the r161643 commit by stoklund, my backend doesn't work anymore. I think I noticed some

Thank for your help. You're right, merging vreg32 and vreg48 is perfectly fine, sorry I missed that. I "brute force" debuged by adding MachineFunction dump after each join, I think I found the issue : it's when vreg32 and vreg10 are merged. vreg10 only appears in BB#3, and the join only occurs in BB#3 apparently even if vreg32 lives in the 4 machine blocks After joining, there