Displaying 7 results from an estimated 7 matches for "bitcasttotype".
2009 Jan 09
2
[LLVMdev] RFC: Store alignment should be LValue alignment, not source alignment
...;INTERNAL ERROR: Referencing decl that hasn't been
laid out");
abort();
@@ -5924,7 +5936,13 @@ LValue TreeToLLVM::EmitLV_DECL(tree exp)
// type void.
if (Ty == Type::VoidTy) Ty = StructType::get(NULL, NULL);
const PointerType *PTy = PointerType::getUnqual(Ty);
- return BitCastToType(Decl, PTy);
+ unsigned Alignment = Ty->isSized() ? TD.getABITypeAlignment(Ty) : 1;
+ if (DECL_ALIGN_UNIT(exp)) {
+ if (DECL_USER_ALIGN(exp) || Alignment <
(unsigned)DECL_ALIGN_UNIT(exp))
+ Alignment = DECL_ALIGN_UNIT(exp);
+ }
+
+ return LValue(BitCastToType(Decl, PTy), Alignmen...
2009 Jan 09
0
[LLVMdev] RFC: Store alignment should be LValue alignment, not source alignment
...as well use 1 here, since compilation is
going to fail anyway.
> @@ -5924,7 +5936,13 @@ LValue TreeToLLVM::EmitLV_DECL(tree exp)
> // type void.
> if (Ty == Type::VoidTy) Ty = StructType::get(NULL, NULL);
> const PointerType *PTy = PointerType::getUnqual(Ty);
> - return BitCastToType(Decl, PTy);
> + unsigned Alignment = Ty->isSized() ? TD.getABITypeAlignment(Ty) : 1;
Can't you just use expr_align here? That said, I'm not sure what
this case is doing.
> + if (DECL_ALIGN_UNIT(exp)) {
> + if (DECL_USER_ALIGN(exp) || Alignment <
> (unsigned)DECL_...
2007 Apr 06
1
[LLVMdev] Integrating LLVM in an existing project
...tion is not "void (void)"). This
is a constant expression, thus cast<Function> asserts. Also, there seems
to be no need to set the CC and linkage because the values set are the
defaults. By the way, I like the use of the C++ only __gxx_personality_v0
here!
(3)
+ TypeInfo = BitCastToType(TypeInfo, PointerType::get(Type::Int8Ty));
This argument is, as far as I can see, just a "cookie" and certainly need
not be an i8*, thus the bitcast. Also, since it is a cookie, shouldn't
the intrinsic be taking an opaque* rather than an i8*?
Ciao,
Duncan.
-------------- next part...
2007 Nov 07
0
[LLVMdev] RFC: llvm-convert.cpp Patch
> How about this patch then?
How about this one :) It passes alignment and volatility around
with DestLoc. It's not finished because I noticed some bugs in
how CopyAggregate and ZeroAggregate handle alignment (problem points
marked with "QQ"). Also, I noticed potential problems with how we
handle call arguments and return results (what if they are strangely
aligned/volatile?),
2007 Apr 06
0
[LLVMdev] Integrating LLVM in an existing project
On Fri, 6 Apr 2007, Nicolas Geoffray wrote:
> Like you say, it's not functional for non-calls instructions. Besides,
> having to change all CalInst to InvokeInst is just too much pain in our
> current vm.
ok.
> Actually, why is it missing? What's the difference between the code
> generator and the JIT?
There are two things missing:
1. Testing and working out the set
2007 Apr 06
2
[LLVMdev] Integrating LLVM in an existing project
Hi Chris,
Chris Lattner wrote:
>> We can not use current exception handling in llvm, see
>> http://www.nondot.org/sabre/LLVMNotes/ExceptionHandlingChanges.txt.
>>
>
> Why not?
>
>
Like you say, it's not functional for non-calls instructions. Besides,
having to change
all CalInst to InvokeInst is just too much pain in our current vm.
> There are two
2007 Nov 07
3
[LLVMdev] RFC: llvm-convert.cpp Patch
How about this patch then?
-bw
Index: gcc/llvm-convert.cpp
===================================================================
--- gcc/llvm-convert.cpp (revision 43658)
+++ gcc/llvm-convert.cpp (working copy)
@@ -758,7 +758,7 @@
}
-Value *TreeToLLVM::Emit(tree exp, Value *DestLoc) {
+Value *TreeToLLVM::Emit(tree exp, Value *DestLoc, unsigned Alignment) {