Displaying 13 results from an estimated 13 matches for "lowerconst".
2015 Dec 14
3
Getting TargetLowering in AsmPrinter / Lowering constant addrspacecast
...of global
variables, at least for the trivial case. The trivial case is if
TargetLowering::isNoopAddrSpaceCast(SrcAS, DestAS) returns true. In
this case the MCExpr for the addrspacecast is the MCExpr of its first
operand.
It seems hard to obtain an instance of TargetLowering in
AsmPrinter::lowerConstant(). Other methods in this class obtain it by
calling `MF->getSubtarget().getTargetLowering()`. However, because MF
is nullptr when lowering initializers of global variables, it won't
work. My impression is that this is not possible because every function
has its own TargetLowering i...
2010 Aug 03
2
[LLVMdev] VMkit AOT build problem: llc crushed on glibj compilation to native(.s) file
...d.zip.s was ~>190Mb when this crush occurred.
> >
> > How this can be corrected?
>
> Attached patch should fix the issue. The unreachable condition was
> caused by a constant expression involving an inttoptr from i32. This
> results in a zext to 64 bits, but apparently LowerConstant in
> AsmPrinter doesn't handle constant expressions involving zext. Aren't
> zext constant expressions supported by LLVM?
>
> - Allan
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu http://llvm....
2010 May 28
1
[LLVMdev] Patch proposal: ARM MC relocations
...st solution, but there were some problems and the fact that this is my
first attempt to change LLVM.
My original assumption was that, changing MCExpr to accept relocation
information, we could propagate that down later to whatever gets written
from it. To change that, one needs to overwrite the LowerConstant function
in AsmPrinter, but that's a static function that rely on other static
functions in the same file. Also, ARMMCInstLower (my first guess) seems to
have not being used to generate anything.
I know that MC is radically changing the area as we speak, so I also didn't
want to spen...
2010 Aug 04
0
[LLVMdev] VMkit AOT build problem: llc crushed on glibj compilation to native(.s) file
...or always trying to do pointer
arithmetic using i32 instead of the target's pointer size, which is
what my patch addressed.
As for whether there is a bug in LLVM, I'm not sure. I've played
around with it some more, and it looks like zext expressions get
constant folded before reaching LowerConstant. The only way I've
triggered the unreachable condition is to make a pointer->i32->pointer
constant expression on a 64bit machine, similar to what vmkit was
doing. Attached is a test case. The commented out expressions don't
trigger the unreachable condition, nor does a simple ze...
2010 Aug 02
0
[LLVMdev] VMkit AOT build problem: llc crushed on glibj compilation to native(.s) file
...c (93Mb),
> glibj-optimized.zip.s was ~>190Mb when this crush occurred.
>
> How this can be corrected?
Attached patch should fix the issue. The unreachable condition was
caused by a constant expression involving an inttoptr from i32. This
results in a zext to 64 bits, but apparently LowerConstant in
AsmPrinter doesn't handle constant expressions involving zext. Aren't
zext constant expressions supported by LLVM?
- Allan
-------------- next part --------------
A non-text attachment was scrubbed...
Name: libvmjc.diff
Type: text/x-patch
Size: 909 bytes
Desc: not available
URL: &l...
2010 Jul 19
2
[LLVMdev] VMkit AOT build problem: llc crushed on glibj compilation to native(.s) file
Hi,
Trying to build AOT version of vmkit java,
building for that classpath glibj.zip:
$ cd vmkit/tools/vmjc/libvmjc
$ make ENABLE_OPTIMIZED=1 DISABLE_ASSERTIONS=1 REQUIRES_FRAME_POINTER=1
has eventually, after 50 minutes, brought:
<<<
llvm[0]: Compiling glibj.zip to llvm
llvm[0]: Optimizing glibj.zip
llvm[0]: Compiling glibj.zip.bc to native
UNREACHABLE executed!
0 llc
2010 Jun 16
2
[LLVMdev] [PATCH] ARM MC relocations
...ion, but there were some problems and the fact that this is my first attempt to change LLVM.
>
> My original assumption was that, changing MCExpr to accept relocation information, we could propagate that down later to whatever gets written from it. To change that, one needs to overwrite the LowerConstant function in AsmPrinter, but that’s a static function that rely on other static functions in the same file. Also, ARMMCInstLower (my first guess) seems to have not being used to generate anything.
>
> I know that MC is radically changing the area as we speak, so I also didn’t want to spen...
2011 Oct 28
1
[LLVMdev] ConstantExpr Handling?
Hi,
I was wondering how exactly LLVM handles the ConstantExpr,
specifically GEP ConstantExpr, in code generation. From what I'm
reading, translating these Constant Expressions into Instructions can
slow the code, so I'd like to be able to handle ConstantExpr in the
same way that LLVM code generation does.
Thanks,
Brandon
2010 Jun 16
0
[LLVMdev] [PATCH] ARM MC relocations
...there were some problems and the fact that this is my first attempt to change LLVM.
>>
>> My original assumption was that, changing MCExpr to accept relocation information, we could propagate that down later to whatever gets written from it. To change that, one needs to overwrite the LowerConstant function in AsmPrinter, but that’s a static function that rely on other static functions in the same file. Also, ARMMCInstLower (my first guess) seems to have not being used to generate anything.
>>
>> I know that MC is radically changing the area as we speak, so I also didn’t want...
2016 Oct 07
2
Proposal: arbitrary relocations in constant global initializers
...getelementptr (i32, i32* bitcast ([3 x
> i32]* @w
> > to i32*), i32 1)
> >
> > This way, you save yourself from needing to worry about manipulating
> addends
> > in the backend, the linker will take care of it for you.
>
> That's no worry at all, AsmPrinter::lowerConstant evaluates both
> constant expressions to MCExpr: w + 4.
>
But you still need to worry about how "w + 4" is represented in the object
file.
> Do you suggest we use this to limit "reloc" to accepting only
> GlobalValue as the second argument instead of an arbitra...
2016 Oct 07
2
Proposal: arbitrary relocations in constant global initializers
...> to i32*), i32 1)
> >> >
> >> > This way, you save yourself from needing to worry about manipulating
> >> > addends
> >> > in the backend, the linker will take care of it for you.
> >>
> >> That's no worry at all, AsmPrinter::lowerConstant evaluates both
> >> constant expressions to MCExpr: w + 4.
> >
> >
> > But you still need to worry about how "w + 4" is represented in the
> object
> > file.
>
> It's a relocation with target "w" and addend "4".
>
So...
2016 Oct 07
2
Proposal: arbitrary relocations in constant global initializers
On Fri, Oct 7, 2016 at 12:20 PM, Evgenii Stepanov <eugeni.stepanov at gmail.com
> wrote:
> I've tried implementing some of the alternatives mentioned in this
> thread, and so far I like this syntax the most:
>
> i32 reloc (29, void ()* @f, 3925868544)
> ; 29 = 0x1d = R_ARM_JUMP24
> ; 3925868544 = 0xea000000
>
> Note the zeroes in the relocated data instead of
2011 May 06
0
[LLVMdev] Question about linking llvm-mc when porting a new backend
...llvm::Mangler::ManglerPrefixTy)", referenced from:
llvm::AsmPrinter::GetExternalSymbolSymbol(llvm::StringRef) constin
libLLVMAsmPrinter.a(AsmPrinter.cpp.o)
"llvm::TargetData::getIndexedOffset(llvm::Type const*, llvm::Value*
const*, unsigned int) const", referenced from:
LowerConstant(llvm::Constant const*, llvm::AsmPrinter&)in
libLLVMAsmPrinter.a(AsmPrinter.cpp.o)
SymbolicallyEvaluateGEP(llvm::Constant* const*, unsigned int,
llvm::Type const*, llvm::TargetData const*)in
libLLVMAnalysis.a(ConstantFolding.cpp.o)
SymbolicallyEvaluateGEP(llvm::Constant* const*, u...