similar to: [LLVMdev] Ho to generate VAARG?

Hi Finkel, Le 23/03/2012 05:50, Hal Finkel a écrit : > The PowerPC backend on PPC64 for non-Darwin (SVR4 ABI) systems > currently has a problem handling integer types smaller than 64 bits. > This is because the ABI specifies that these types are zero-extended to > 64 bits on the stack and the default logic provided in LegalizeDAG does > not use that convention. Specifically, for

The PowerPC backend on PPC64 for non-Darwin (SVR4 ABI) systems currently has a problem handling integer types smaller than 64 bits. This is because the ABI specifies that these types are zero-extended to 64 bits on the stack and the default logic provided in LegalizeDAG does not use that convention. Specifically, for these targets we have: setOperationAction(ISD::VAARG, MVT::Other, Expand);

Le 23/03/2012 17:02, Hal Finkel a écrit : > On Fri, 23 Mar 2012 09:50:12 +0100 > Ivan Llopard<ivanllopard at gmail.com> wrote: > >> Hi Finkel, >> >> Le 23/03/2012 05:50, Hal Finkel a écrit : >>> The PowerPC backend on PPC64 for non-Darwin (SVR4 ABI) systems >>> currently has a problem handling integer types smaller than 64 bits. >>> This

On Tue, 3 Apr 2007, Nicolas Geoffray wrote: > A VAARG call requires a lot of computation. Typically the C code for > va_arg(ap, int) If you use va_arg in C, are you seeing llvm.vaarg in the output .ll file? -Chris > is: > > int va_arg_gpr(ap_list ap) { > int idx = ap->gpr; > if (idx < 8) { > ap->gpr = idx + 1; > return

On Fri, 23 Mar 2012 09:50:12 +0100 Ivan Llopard <ivanllopard at gmail.com> wrote: > Hi Finkel, > > Le 23/03/2012 05:50, Hal Finkel a écrit : > > The PowerPC backend on PPC64 for non-Darwin (SVR4 ABI) systems > > currently has a problem handling integer types smaller than 64 bits. > > This is because the ABI specifies that these types are > > zero-extended

I'm generating code for a target that only supports i32 natively. My front end is generating VAARG for accessing varargs parameters. The problem is that I get an assert when I compile this: #include <stdarg.h> int main(va_list ap) { typedef double type; type tmp; tmp = va_arg(ap, type); } Bitcode: ; ModuleID = 't0056.bc' target datalayout =

Hi Chris, Chris Lattner wrote: > On Tue, 3 Apr 2007, Nicolas Geoffray wrote: > >> A VAARG call requires a lot of computation. Typically the C code for >> va_arg(ap, int) >> > > If you use va_arg in C, are you seeing llvm.vaarg in the output .ll file? > I'm guessing that if you're asking, then no llvm.vaarg is generated. I can not test it on my

Hi everyone, I'm implementing varags handling for PPC32 with the ELF ABI. It is largely more complicated than the Macho ABI or x86 because it manipulates a struct instead of a direct pointer in the stack. You can find the layout of the va_list struct at the end of this mail. A VAARG call requires a lot of computation. Typically the C code for va_arg(ap, int) is: int va_arg_gpr(ap_list

I guess not since Value is a superclass of Instruction. On Mon, Feb 6, 2012 at 10:36 AM, Ryan Taylor <ryta1203 at gmail.com> wrote: > > > ---------- Forwarded message ---------- > From: Ryan Taylor <ryta1203 at gmail.com> > Date: Mon, Feb 6, 2012 at 10:36 AM > Subject: Re: [LLVMdev] Updating PHI for Instruction Domination? > To: Eric Christopher <echristo at

---------- Forwarded message ---------- From: Ryan Taylor <ryta1203 at gmail.com> Date: Mon, Feb 6, 2012 at 10:36 AM Subject: Re: [LLVMdev] Updating PHI for Instruction Domination? To: Eric Christopher <echristo at apple.com> Since I'm not sure which instructions I might want to replicate, would it be possible to cast the Value from "PHINode::getIncomingValue" to

You're creating a new path that doesn't include L. For all values defined in L and used outside of L, you need to determine the new reaching def. That's specific to your transformation and can't be automated. Once you do that, creating the phi in F is natural. -Andy On Feb 6, 2012, at 11:51 AM, Ryan Taylor <ryta1203 at gmail.com> wrote: > I guess not since Value is a

Dear guys, I am having problems to obtain good information from the LoopInfo. I am always getting a trip count of 0, even though I am clearly passing a loop with a constant bound. I am using this pass below: void testLoopInfo(const Function& F) const { const LoopInfo *LI = &getAnalysis<LoopInfo>(); Function::const_iterator BB = F.begin(), E = F.end(); for (; BB !=

I guess I didn't have a clear question. Suppose we have BB1 and BB2 both point to BB3. BB1 has variable x. BB2 also as variable x. BB3 will have PHINode for x with 2 value from BB1 and BB2. BB1 BB2 \ / BB3 Now if BB1 and BB2 is extracted into a function (using ExtractCodeRegion), they will be replaced by a basic block called codeRepl (which has a call to the extracted

On May 22, 2014, at 3:51 PM, Chandler Carruth <chandlerc at google.com> wrote: > > On Thu, May 22, 2014 at 4:42 PM, Louis Gerbarg <lgg at apple.com> wrote: > The problem that the above transform is technically illegal because “When indexing into a (optionally packed) structure, only i32 integer constants are allowed (when using a vector of indices they must all be the same

Hi all, I am using "lm" to fit some anova factor models with interactions. The default setting for my unordered factors is "treatment". I understand the resultant "lm" coefficients for one factors, but when it comes to the interaction term, I got confused. > options()$contrasts unordered ordered "contr.treatment"

----- Original Message ----- > From: "Chandler Carruth" <chandlerc at google.com> > To: "Louis Gerbarg" <lgg at apple.com> > Cc: "LLVM Developers Mailing List" <llvmdev at cs.uiuc.edu> > Sent: Thursday, May 22, 2014 7:09:49 PM > Subject: Re: [LLVMdev] RFC: Indexing of structs vs arrays in getelementpointer > > > > >

On 01/26/2011 07:50 PM, Vu Le wrote: > I guess I didn't have a clear question. > > Suppose we have BB1 and BB2 both point to BB3. > BB1 has variable x. BB2 also as variable x. > BB3 will have PHINode for x with 2 value from BB1 and BB2. > BB1 BB2 > \ / > BB3 > > Now if BB1 and BB2 is extracted into a function > (using ExtractCodeRegion), they

Hi, I am trying to prune some uninteresting llvm ir branches, corresponding to the *if-else* condition in the source code. And here is the procedures: 1. Get the BasicBlock containing the BranchInst which has 2 successors(in order to keep consistent with the source code I am using the llvm ir without any optimizations, so SelectInst/SwitchInst/PHINode is absent), one of which should be

Hi Tobias, If the PHI node at exit block of region R has multiple inputs from the R, I split the exit block into 2. The first block contains all PHI nodes whose input are all from the region. The second is the new exit node. All branches (outside R) to the old exit now point the new exit. All regions whose exit is the old exit are also updated with the new exit node. It works like a charm.

Hi John, On 30/07/13 16:12, John Criswell wrote: > Dear All, > > Is there a pass (or set of passes) that will replace a phi whose input operands > all compute the same value with an instruction that computes that value? In > other words, something that will convert: > > define internal i32 @function(i32 %x) { > ... > bb1: > %y = add %x, 10 > ... > bb2: > %z