search for: multiplereturnvalu

..., it > probably has very localized impact in the code. Are there other good > reasons not to add this capability, or would a patch adding it stand > a good chance to be accepted? Chris has some notes about how to do this for return values here: http://www.nondot.org/sabre/LLVMNotes/MultipleReturnValues.txt — Gordon

Hello, I'm trying to port the XL compiler (http://xlr.sf.net) to use the LLVM back-end. So far, little trouble doing so. But there is one aspect of the semantics of the LLVM IR that surprises me. Why are the call, declare and define "halfway through" ABI conventions? I think it's the right thing to have a single high level node for each call, as opposed to separate

...em is > the 'void' type, which is only currently allowed as the return value > of a function. Special cases like this should be eliminated. Is this still the case, and if so, is there any work being done on this already? Thanks! Patrick [1] http://www.nondot.org/~sabre/LLVMNotes/MultipleReturnValues.txt

Hi, I was looking at LLVM as a target for EHC (http://catamaran.labs.cs.uu.nl/twiki/st/bin/view/Ehc) which is a Haskell compiler. I got some questions on the status of LLVM. I read some discussions on tail calls, and was wondering if they are implemented. Furthermore many comments in lib/Target/.. state: '// FIXME: Implement the invoke/unwind instructions!' I understood this is an old

LegalizeDAG.cpp SDOperand SelectionDAGLegalize::LegalizeOp(SDOperand Op) { case ISD::RET: Tmp1 = LegalizeOp(Node->getOperand(0)); // Legalize the chain. switch (Node->getNumOperands()) { case 2: // ret val [skipped] case 1: // ret void [skipped] default: { // ret <values> [skipped] Does it imply that a ret instruction may

...on was 4 loads, two fp adds, and 2 stores for C++, as opposed to only the fp adds for XL. Obviously, an IR assuming that aggregates are in memory does not help here. >> > Chris has some notes about how to do this for return values here: > > http://www.nondot.org/sabre/LLVMNotes/MultipleReturnValues.txt He pointed me to this earlier, thanks. Thanks, Christophe

Hello A suggestion to LLVM (assembly) language designers. It could be worthwhile to extend the LLVM language http://llvm.org/docs/LangRef.html#i_call so that calls may return more than one result (for example, Common lisp functions can return more than one result). The intent could be to extend the ABI calling conventions to permit a function to return a few results (all in registers), instead

Reid Spencer wrote: > In order to get to the next stage with LLVM (like compiling a kernel) we > need to allow "pass through" of inline assembly so things like device > drivers, interrupt vectors, etc. can be written. While this feature > breaks the "pure" LLVM IR, I don't see any way around it. <shameless plug> Actually, there should be a way around it.

In order to get to the next stage with LLVM (like compiling a kernel) we need to allow "pass through" of inline assembly so things like device drivers, interrupt vectors, etc. can be written. While this feature breaks the "pure" LLVM IR, I don't see any way around it. So, I thought I'd bring it up here so we can discuss potential implementations. I think we should