similar to: [LLVMdev] Non-Chain Chains

Philip Reames wrote: > Any change outside of statepoint lowering is highly suspect. Notice that SelectionDAGBuilder::LowerCallTo (the one I'm modifying) has exactly one other caller: visitCall, which doesn't match vararg functions. Every other codepath directly calls TargetLowering::LowerCallTo, supplying CallLoweringInfo information explicity (it's a structure with a vararg

Hi, In LLVM, responsibility of legalizing all the illegal types lies on type legalizer. Why is type legalization of ISD::CALL (call arguments and call return) and ISD::RET nodes being done much earlier? (e.g. for call in visitCall - through function LowerCallTo) Regards Sachin -------------- next part -------------- An HTML attachment was scrubbed... URL:

On 01/08/2013 01:48 PM, Eli Friedman wrote: > On Mon, Jan 7, 2013 at 6:07 PM, reed kotler <rkotler at mips.com> wrote: >> For example: >> >> /home/rkotler/llvm/install/bin/llc -mcpu=mips16 hf16_2.ll -march=mipsel >> -relocation-model=pic -o hf16_2.s -O3 -mips16-hard-float -soft-float > Try something like the following: > > float f; > double test(void*

> what does "refuses to compile" mean? I.e. what error do you get? > Specifically I get this message when compiling with the default -mattr: Call result #2 has unhandled type i32 UNREACHABLE executed at CallingConvLower.cpp:162! 0 llc 0x0000000100a1e115 PrintStackTrace(void*) + 38 1 llc 0x0000000100a1e6d0 SignalHandler(int) + 254 2

Hi, > In LLVM, responsibility of legalizing all the illegal types lies on type > legalizer. > > Why is type legalization of ISD::CALL (call arguments and call return) > and ISD::RET nodes being done much earlier? > > (e.g. for call in visitCall - through function LowerCallTo) I don't know. Perhaps the legal version is needed very early on? Maybe Chris can answer?

On Tue, Jan 8, 2013 at 6:33 PM, reed kotler <rkotler at mips.com> wrote: > On 01/08/2013 01:48 PM, Eli Friedman wrote: >> >> On Mon, Jan 7, 2013 at 6:07 PM, reed kotler <rkotler at mips.com> wrote: >>> >>> For example: >>> >>> /home/rkotler/llvm/install/bin/llc -mcpu=mips16 hf16_2.ll -march=mipsel >>> -relocation-model=pic -o

Hello, I am working on a backend for a custom ISA that is somewhat similar to the MicroBlaze ISA so I've decided to use that as a starting point. I am trying to compile a custom ray tracer (lots of floating point) and the llvm-g++ frontend generates an fneg instruction which is not supported by the MBlaze backend in the 2.8 release. I added code to emit an fneg assembly instruction and now

Dear colleagues, I'm looking if we can replace nvopencc with LLVM NVPTX in our project. It turns NVPTX won't work with the code nvopencc can handle (please see the log below). So are atomic intrinsics not supported or am I doing call in a wrong way? Thanks, - Dima. SOURCE ======== dmikushin at hp2:~> cat kernelgen_monitor.ll ; ModuleID =

In response to this discussion, I've prepared the attached patch as an initial prototype for the LowerCall/LowerCallTo change. All of the information currently needed by the back-ends, and the extra information needed by the NVPTX back-end, is now wrapped in a CallLoweringInfo struct. The various SelectionDAG classes have been modified so any calls to TargetLowering::LowerCallTo use this

Bill Wendling wrote: > On Dec 31, 2008, at 5:57 AM, srs wrote >> Bill Wendling wrote: >> >>> On Dec 30, 2008, at 4:51 PM, srs wrote: >>> >>> >>> >>>> 2. There seems to be an issue in ScheduleDAGSDNodes.h when in debug >>>> mode. The problem is the evaluation of "&SUnits[0];" which

On Dec 31, 2008, at 5:57 AM, srs wrote: > Bill Wendling wrote: >> On Dec 30, 2008, at 4:51 PM, srs wrote: >> >> >>> 2. There seems to be an issue in ScheduleDAGSDNodes.h when in debug >>> mode. The problem is the evaluation of "&SUnits[0];" which >>> ASSERT's in >>> VC++'s vector[] implementation (when

> -----Original Message----- > From: Dmitry N. Mikushin [mailto:maemarcus at gmail.com] > Sent: Wednesday, May 16, 2012 5:44 AM > To: LLVM-Dev > Cc: Justin Holewinski > Subject: NVPTX: __iAtomicCAS support ? > > Dear colleagues, > > I'm looking if we can replace nvopencc with LLVM NVPTX in our project. > It turns NVPTX won't work with the code nvopencc

Hi all, While testing my compiler on win32 in JIT mode, I ran into a couple of issues: 1. I linked the compiler with the lib files resulting from the cmake created VS.NET build. While everything built just fine, the ExecutionEngine::create call always returned NULL. The fix was to also link with JIT.obj (thanks aKor for pointing me in the right direction). I would have thought that linking

> -----Original Message----- > From: Evan Cheng [mailto:evan.cheng at apple.com] > Sent: Wednesday, May 16, 2012 5:30 PM > To: Justin Holewinski > Cc: llvmdev at cs.uiuc.edu; llvm-commits at cs.uiuc.edu > Subject: Re: [llvm-commits] [PATCH][RFC] Add extra arguments to > TargetLowering::LowerCall() so targets have more context in which to > construct call chains > >

From: Evan Cheng [mailto:evan.cheng at apple.com] Sent: Thursday, April 19, 2012 10:47 AM To: Justin Holewinski Cc: llvmdev at cs.uiuc.edu; llvm-commits at cs.uiuc.edu; Vinod Grover Subject: Re: [llvm-commits] [PATCH][RFC] Add extra arguments to TargetLowering::LowerCall() so targets have more context in which to construct call chains TargetLowering::LowerCall is already a mess, I would really

On Apr 19, 2012, at 12:46 PM, Evan Cheng <evan.cheng at apple.com> wrote: > > On Apr 19, 2012, at 11:15 AM, Justin Holewinski wrote: > >> >> From: Evan Cheng [mailto:evan.cheng at apple.com] >> Sent: Thursday, April 19, 2012 10:47 AM >> To: Justin Holewinski >> Cc: llvmdev at cs.uiuc.edu; llvm-commits at cs.uiuc.edu; Vinod Grover >> Subject:

On Apr 19, 2012, at 11:15 AM, Justin Holewinski wrote: > > From: Evan Cheng [mailto:evan.cheng at apple.com] > Sent: Thursday, April 19, 2012 10:47 AM > To: Justin Holewinski > Cc: llvmdev at cs.uiuc.edu; llvm-commits at cs.uiuc.edu; Vinod Grover > Subject: Re: [llvm-commits] [PATCH][RFC] Add extra arguments to TargetLowering::LowerCall() so targets have more context in which

Thanks. This is going in the right direction IMHO. Obviously, please make sure you add comments to the data structure and convert all the targets first. Also, please don't forget to send an email to llvmdev to warn owners of all the out-of-tree targets about the ABI change. Evan On May 15, 2012, at 6:56 AM, Justin Holewinski <jholewinski at nvidia.com> wrote: > In response to this

Right, later in the same file we have: // Reserve entries in the vector for each of the SUnits we are creating. This // ensure that reallocation of the vector won't happen, so SUnit*'s won't get // invalidated. // FIXME: Multiply by 2 because we may clone nodes during scheduling. // This is a temporary workaround. SUnits.reserve(NumNodes * 2); So for some reason *2 is

Hello, I was trying to interface a custom backend instruction scheduler with llvm code when I realize something terrible. The scheduling code builds a graph made up of SUnit * nodes (see ScheduleDAG*.{cpp,h}). These SUnits nodes are allocated via a std::vector< SUnit >. This isn't a problem as long as the pointers are taken after the vector is fully filled and the vector never changes