search for: ghccc

...proposed 'cps' call: ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; define { ... } @foo (i8** %sp, ...) { someBlk: ; ... ; finish stack frame by writing return address %retAddr = blockaddress(@foo, %retpt) store i8* %retAddr, i8** %sp ; jump to @bar %retVals = cps call ghccc {i8**, i64} @bar (i8** %sp, ...) br label %retpt retpt: %sp2 = extractvalue {i8**, i64} %retVals, 0 %val = extractvalue {i8**, i64} %retVals, 1 ; ... } define {i8**, i64} @bar (i8** %sp, ...) { ; perform a return %retAddr0 = load i8*, i8** %sp %retAddr1 = bitcast i8* %retA...

...g alone are problematic enough to warrant serious hesitation. There are nicer ways to embed CPS call/return into LLVM; I just figured that there would not be much support for adding a new terminator because it would change a lot of code. Ideally we would have a block terminator like: cps call ghccc @bar (.. args ..) returnsto label %retpt Where the "returnsto" is optional to cover both CPS calls and returns. Another alternative would be to emulate this terminator using an intrinsic. So, my question is: would there be more support for a version of this terminator (whether as an int...

...;;;;;;;;;;;;; >> define { ... } @foo (i8** %sp, ...) { >> someBlk: >> ; ... >> ; finish stack frame by writing return address >> %retAddr = blockaddress(@foo, %retpt) >> store i8* %retAddr, i8** %sp >> ; jump to @bar >> %retVals = cps call ghccc {i8**, i64} @bar (i8** %sp, ...) >> br label %retpt >> retpt: >> %sp2 = extractvalue {i8**, i64} %retVals, 0 >> %val = extractvalue {i8**, i64} %retVals, 1 >> ; ... >> } >> define {i8**, i64} @bar (i8** %sp, ...) { >> ; perform a return >...

...function '@stg_gc_f1' [1] 85435 segmentation fault llc -O2 -mcpu=generic HeapStackCheck.ll -mattr=+soft-float -o $ llc -O2 -mcpu=generic rts/HeapStackCheck.ll -float-abi=soft -o rts/HeapStackCheck.s will succeed however. Given your explanation, this might be due to the fact how the `ghccc` tries to pass everything is registers. And which is why this falls apart when float registers are used. Maybe the lesson here is that a few more adjustments in GHC are needed to not emit code using float registers if we use soft float. I still don’t understand why `-float-abi=soft` would compile...

Hi, I have this function: ``` define private ghccc void @c4JC_info(i32*, i32*, i32*, i32, i32, i32, i32, i32) prefix { i32, i32, i32 } { i32 add (i32 sub (i32 ptrtoint ({ i32, i32, i32, i32, i32, i32, i32, i32, i32, i32, i32, i32, i32, i32, i32, i32, i32, i32, i32, i32 }* @S4J7_srt to i32), i32 ptrtoint (void (i32*, i32*, i32*, i32, i32, i32, i32,...

...utside of the module, could the endianness be set there prior to entering the function? The working module contains the main directly and is not called from a main function in a different module. I've also tried to define a regular c function with the same code and called that from within the ghccc function with the same (incorrect) results. Any further ideas I could expore? Cheers, Moritz > On Dec 1, 2017, at 4:26 PM, Tim Northover <t.p.northover at gmail.com> wrote: > > Hi Moritz, >> If someone could offer some hint, where to look further for debugging this, I'...

...`armv7-apple-darwin`, unless optimization level is 0, however it fails to compile at all for `armv7-apple-ios`. I was able to reduce the produced code, while retaining the compilation issue on `armv7-apple-ios` to the following sample case: ————————————————————— 8< ————————————————————— define ghccc void @"f$def"(i32* noalias nocapture %Base_Arg, i32* noalias nocapture %Sp_Arg, i32* noalias nocapture %Hp_Arg, i32 %R1_Arg, i32 %R2_Arg, i32 %R3_Arg, i32 %R4_Arg, i32 %SpLim_Arg,...

Hi Moritz, On 26 September 2017 at 09:09, Moritz Angermann via llvm-dev <llvm-dev at lists.llvm.org> wrote: > I’ve run into a case where `llc -mattr=+soft-float` for > "armv7-unknown-linux-androideabi” segfaults, while > `llc -float-abi=soft` does not. Similarly if the > "target-features"="+soft-float” metadata is embedded, > llc segfaults. The float-abi

Hi, I’ve run into a case where `llc -mattr=+soft-float` for "armv7-unknown-linux-androideabi” segfaults, while `llc -float-abi=soft` does not. Similarly if the "target-features"="+soft-float” metadata is embedded, llc segfaults. I fear I’m missing something rather subtle here, could someone help me understand the differences? Cheers, Moritz

...sses to be required? Could llvm be taught >> that say a certain calling convention needs a pass to run? > > This could be done, but we’d need to here more about the motivation. I suspect the solution may end up different if we understand the exact use-case. Sure. This is all about the ghccc. Here the original discussion between Chris Lattner and David Terei who initially implemented the llvm backend for ghc: http://www.nondot.org/sabre/LLVMNotes/GlobalRegisterVariables.txt Cheers, moritz > — > Mehdi > > > >> >> Cheers, >> Moritz >> >...

...he following machine code for a call (I'll use an x86-64 example): leaq _retpt(%rip), %scratchReg movq %scratchReg, (%ghcSPReg) jmp _bar But, if we want to end up with the above machine code using a custom lowering of just the following IR instruction, %retVals = cps call ghccc @bar (... args ...) _without_ explicitly taking the block address and writing it to the GHC stack pointer beforehand, there are some things to consider: 1. How do we prevent IR optimizations from eliminating the %retpt block? If we do not explicitly take the address of the %retpt block, a pas...

...t;> >> define { ... } @foo (i8** %sp, ...) { >> someBlk: >> ; ... >> ; finish stack frame by writing return address >> %retAddr = blockaddress(@foo, %retpt) >> store i8* %retAddr, i8** %sp >> ; jump to @bar >> %retVals = cps call ghccc {i8**, i64} @bar (i8** %sp, ...) >> br label %retpt > > I'm not following how explicitly representing the return address of a call in the IR before isel actually solves any relevant issue. We already pass the return address implicitly as an argument to every call; you can retrie...

Hi Matthias, what I’m observing right now is that replacing opt+llc with an clang invocation, and subsequently fewer intermediate files, increases the consumed time with -O0 by 200%. We used to always run opt with -mem2reg -globalopt, and I believe those are not part of -O0 (is there an easy way to list all passes that -OX flags to clang imply for the optimizer and code gen?). Could the IR imply