Displaying 20 results from an estimated 20000 matches similar to: "[LLVMdev] Byval arguments with alignment"
2010 Apr 27
2
[LLVMdev] Setting alignment for a ByVal argument
Hi,
Thanks for the help. I tried this out, but on x86_64 and with llvm 2.6
and llvm-gcc 4.2.1, I dont seem to get an aligned variable.
This is the function definition that I have
define internal fastcc void @walksub(%struct.hgstruct* noalias
nocapture sret %agg.result, %struct.node* %p, double %dsq,
%struct.hgstruct* byval align 64 %hg, i32 %level) nounwind {
And these are the call sites,
2010 Apr 28
1
[LLVMdev] Setting alignment for a ByVal argument
I could not get the same .bc file work with llvm 2.7 on x86_64 either.
This is the address I got for a byval argument meant to be aligned to
64byte boundary.
0x7fff3f0ae030
Any more pointers?
Arushi
PS: Is the IR representation in 2.7 any different, that I should not
use the same bitcode file.
On Tue, Apr 27, 2010 at 3:22 PM, Duncan Sands <baldrick at free.fr> wrote:
> Hi Arushi,
2010 Apr 26
2
[LLVMdev] Setting alignment for a ByVal argument
Hi,
If I want a particular alignment on a ByVal argument, should I specify
it as a function attribute, or should I also add the attribute to
every callsite that calls that function.
Thanks,
Arushi
2010 Apr 27
0
[LLVMdev] Setting alignment for a ByVal argument
Hi Arushi,
> If I want a particular alignment on a ByVal argument, should I specify
> it as a function attribute, or should I also add the attribute to
> every callsite that calls that function.
in theory you should do both. For example, if the call is an indirect call
(i.e. to a function pointer where the function is not known) then it should
be clear that you need to put the
2010 Apr 27
0
[LLVMdev] Setting alignment for a ByVal argument
Hi Arushi,
> Thanks for the help. I tried this out, but on x86_64 and with llvm 2.6
> and llvm-gcc 4.2.1, I dont seem to get an aligned variable.
does it work with llvm-2.7 (just released)?
Ciao,
Duncan.
2010 Mar 09
3
[LLVMdev] Alignment for Alloca Inst in llvm 2.6
Hi,
1. Does the alignment of the pointer returned by an AllocaInst depend on the
instructions before it in the basic block? The 1st snippet below aligns 'a'
correctly, while the 2nd one doesnt. (the method handle_args, only prints
out the values of arguments, and returns argv unchanged).
define i32 @main(i32 %argc, i8** %argv) nounwind {
entry:
%argc_addr = alloca i32
2010 Mar 09
0
[LLVMdev] Alignment for Alloca Inst in llvm 2.6
On 8 March 2010 19:51, Arushi Aggarwal <arushi987 at gmail.com> wrote:
>
> 2. I notice that the setAlignment method for an AllocaInst takes an
> unsigned. For 64 bit systems, alignment could potentially be larger. Is
> there a reason why the alignment should be restricted to this size?
> Thanks in advance
>
Would it ever be practical to align a stack variable to an 8 GiB
2011 Apr 05
3
[LLVMdev] GEP vs IntToPtr/PtrToInt
On Mon, Apr 4, 2011 at 5:02 PM, Arushi Aggarwal <arushi987 at gmail.com> wrote:
>
>
>> Hi,
>> Is it correct to convert,
>> %196 = load i32* %195, align 8 ; <i32> [#uses=1]
>> %197 = zext i32 %196 to i64 ; <i64> [#uses=1]
>> %198 = ptrtoint i8* %193 to i64 ; <i64> [#uses=1]
2010 Dec 13
1
[LLVMdev] How can I determine safely if a CallSite is "live" in a DSGraphs context
Hi,
I believe shouldHaveNodeForValue() should return false for
ConstantPointerNullValue.
Fixed in r121707.
Arushi
On Mon, Dec 13, 2010 at 12:10 PM, Kevin Streit
<kevin.streit at googlemail.com>wrote:
> I'm using BUDataStructures... But I tried LocalDatastructures and it didn't
> work either...
> On Dec 13, 2010 6:52 PM, "Arushi Aggarwal" <arushi987 at
2011 Apr 04
2
[LLVMdev] GEP vs IntToPtr/PtrToInt
On 4/4/2011 6:45 PM, Eli Friedman wrote:
> On Mon, Apr 4, 2011 at 5:02 PM, Arushi Aggarwal<arushi987 at gmail.com> wrote:
>>
>>> Hi,
>>> Is it correct to convert,
>>> %196 = load i32* %195, align 8 ;<i32> [#uses=1]
>>> %197 = zext i32 %196 to i64 ;<i64> [#uses=1]
>>> %198 =
2011 Aug 17
2
[LLVMdev] Is va_arg deprecated?
FWIW, attached is a similar patch that adds a -falways-use-llvm-vaarg
flag to Clang.
Applies against mainline.
(As discussed, va_arg isn't really supported well so this probably
doesn't work well on anything other than simple code, YMMV, etc)
~Will
On Thu, May 12, 2011 at 12:29 PM, Arushi Aggarwal <arushi987 at gmail.com> wrote:
> Have these changes made it to mainline? Is
2011 Apr 05
0
[LLVMdev] GEP vs IntToPtr/PtrToInt
This code is generated for va_arg.
%6 = getelementptr inbounds %struct.__va_list_tag* %5, i32 0, i32 3 ; <i8**>
[#uses=1]
%7 = load i8** %6, align 8 ; <i8*> [#uses=1]
%8 = getelementptr inbounds [1 x %struct.__va_list_tag]* %ap, i64 0, i64 0
; <%struct.__va_list_tag*> [#uses=1]
%9 = getelementptr inbounds %struct.__va_list_tag* %8, i32 0, i32 0 ;
2011 Aug 17
0
[LLVMdev] Is va_arg deprecated?
On Aug 17, 2011, at 11:53 AM, Will Dietz wrote:
> FWIW, attached is a similar patch that adds a -falways-use-llvm-vaarg
> flag to Clang.
>
> Applies against mainline.
>
> (As discussed, va_arg isn't really supported well so this probably
> doesn't work well on anything other than simple code, YMMV, etc)
>
> ~Will
>
> On Thu, May 12, 2011 at 12:29 PM,
2011 May 04
1
[LLVMdev] Loop-Unroll optimization
1. You should run the passes in the same opt command, for passes like loops
which is an analysis pass provides results to the following passes.
2. You can pass a -debug flag to opt to see the some debugging info.
3. I tried this
opt -mem2reg -loops -loopsimplify -loop-unroll -unroll-count=3 -debug
loop.o -o tt.bc
and got this message.
Loop Size = 14
Can't unroll; loop not terminated by
2010 Apr 21
0
[LLVMdev] Function pointers bitcasted to varargs
Do you compile this as C? In C, unlike in C++, empty parenthesis do
not mean "no arguments", they mean "no prototype", which is typically
treated the same way as varargs in calling conventions. To declare
function with no arguments do typedef void (*FP)(void);
Eugene
On Wed, Apr 21, 2010 at 10:22 PM, Arushi Aggarwal <arushi987 at gmail.com> wrote:
> Hi all,
>
>
2011 Aug 17
2
[LLVMdev] Is va_arg deprecated?
To get clang to emit va_arg instructions for va_arg() calls, as
opposed to manually lowering it in the frontend, same as the llvm-gcc
patch sent earlier does.
~Will
On Wed, Aug 17, 2011 at 2:41 PM, Eric Christopher <echristo at apple.com> wrote:
>
> On Aug 17, 2011, at 11:53 AM, Will Dietz wrote:
>
>> FWIW, attached is a similar patch that adds a -falways-use-llvm-vaarg
2011 Apr 05
0
[LLVMdev] GEP vs IntToPtr/PtrToInt
On Mon, Apr 4, 2011 at 7:10 AM, John Criswell <criswell at illinois.edu> wrote:
> On 4/4/2011 6:45 PM, Eli Friedman wrote:
>>
>> On Mon, Apr 4, 2011 at 5:02 PM, Arushi Aggarwal<arushi987 at gmail.com>
>> wrote:
>>>
>>>> Hi,
>>>> Is it correct to convert,
>>>> %196 = load i32* %195, align 8
2011 Apr 06
0
[LLVMdev] Incompatible types at call site
Unoptimized IR
%tmp63 = call %struct.TypHeader* (...)* bitcast (%struct.TypHeader*
(%struct.TypHeader*, i64, i64)* @Cyclotomic to %struct.TypHeader*
(...)*)(%struct.TypHeader* %tmp62, i64 %tmp24, i32 1) nounwind, !dbg !907 ;
<%struct.TypHeader*> [#uses=1]
Optimized IR
%tmp63 = call%struct.TypHeader*
(%struct.TypHeader*, i64, i64)* @Cyclotomic (%struct.TypHeader* %tmp62, i64
%tmp24,
2011 May 16
0
[LLVMdev] Upgrading to llvm-2.9
namespace llvm {
class PassRegistry;
void initializeFooPass(PassRegistry&);
}
using namespace llvm;
namespace {
class Foo : public ModulePass {
public:
static char ID;
Foo() : ModulePass(ID) {
initializeFooPass(*PassRegistry::getPassRegistry());
}
bool runOnModule(Module& M) {
M.dump();
return false;
}
};
}
char Foo::ID = 0;
2011 Aug 17
0
[LLVMdev] Is va_arg deprecated?
I should have been more specific:
"Why do we want this as an option? Do we want it on all the time? Why or why not?"
-eric
On Aug 17, 2011, at 3:02 PM, Will Dietz wrote:
> To get clang to emit va_arg instructions for va_arg() calls, as
> opposed to manually lowering it in the frontend, same as the llvm-gcc
> patch sent earlier does.
>
> ~Will
>
> On Wed, Aug