Displaying 9 results from an estimated 9 matches for "_z4testv".
2012 Jun 12
2
[LLVMdev] [NVPTX] For linkonce_odr NVPTX generates .weak, but even newest PTXAS can't handle it
...x64-unknown-unknown -fcuda-is-device
test3.cu -o test3.ll
> cat test3.ll
; ModuleID = 'test3.cu'
target datalayout = "e-p:64:64-i64:64:64-f64:64:
64-n1:8:16:32:64"
target triple = "ptx64-unknown-unknown"
@llvm.used = appending global [1 x i8*] [i8* bitcast (void ()* @_Z4testv to
i8*)], section "llvm.metadata"
define linkonce_odr ptx_device void @_Z4testv() nounwind inlinehint {
entry:
ret void
}
> llc -march=nvptx64 -mcpu=sm_20 test3.ll -o test3.ptx
> cat test3.ptx
//
// Generated by LLVM NVPTX Back-End
//
.version 3.0
.target sm_20, texmode_indepe...
2012 Jun 13
0
[LLVMdev] [NVPTX] For linkonce_odr NVPTX generates .weak, but even newest PTXAS can't handle it
...t; test3.cu -o test3.ll
> > cat test3.ll
> ; ModuleID = 'test3.cu'
> target datalayout = "e-p:64:64-i64:64:64-f64:64:
> 64-n1:8:16:32:64"
> target triple = "ptx64-unknown-unknown"
>
> @llvm.used = appending global [1 x i8*] [i8* bitcast (void ()* @_Z4testv
> to i8*)], section "llvm.metadata"
>
> define linkonce_odr ptx_device void @_Z4testv() nounwind inlinehint {
> entry:
> ret void
> }
>
> > llc -march=nvptx64 -mcpu=sm_20 test3.ll -o test3.ptx
> > cat test3.ptx
>
> //
> // Generated by LLVM NVPT...
2015 Jan 27
2
[LLVMdev] RFC: Native Windows C++ exception handling
Hi Reid,
Thanks for the input.
You wrote:
> The @_Z4testv.unwind.1 helper just calls ~Inner(), but not ~Outer.
That’s actually intentional. The thing to keep in mind is that all of the landing pads are going to be effectively removed by the time the final object image is generated. They are just there to facilitate the table generation, and in the __Cx...
2015 Jan 26
2
[LLVMdev] RFC: Native Windows C++ exception handling
I am working on adding support for C++ exception handling when compiling for a native Windows target (that is a target with "MSVC" specified as the environment). Because of differences between how the native Windows runtime handles exceptions and the Itanium-based model used by current LLVM exception handling code, I believe this will require some extensions to the LLVM IR, though
2015 Jan 27
2
[LLVMdev] RFC: Native Windows C++ exception handling
...r;
try {
Inner inner;
do_inner_thing();
} catch (int) {
handle_int();
}
} catch (float) {
handle_float();
}
keep_going();
}
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
; Original
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
; Function Attrs: uwtable
define void @_Z4testv() #0 {
entry:
%outer = alloca %class.Outer, align 1
%inner = alloca %class.Inner, align 1
call void @llvm.eh.setehstate(i32 0)
invoke void @_ZN5OuterC1Ev(%class.Outer* %outer)
to label %invoke.cont unwind label %lpad
invoke.cont:
call void @llvm.eh.setehstate(i32 1)
call void...
2015 Mar 20
2
[LLVMdev] LLVM Exception Handling
...ry(std::move(Mod));
factory.setErrorStr(&err);
factory.setEngineKind(llvm::EngineKind::JIT);
factory.setTargetOptions(Opts);
factory.setMCJITMemoryManager(std::move(MemMgr));
llvm::ExecutionEngine* EE = factory.create();
llvm::sys::DynamicLibrary::AddSymbol("_Z4testv",
reinterpret_cast<void*>(test));
EE->finalizeObject();
void* poi = EE->getPointerToFunction(f);
void (*exec)(void*) = reinterpret_cast<void (*)(void*)>(poi);
try {
exec(NULL);
} catch (int e) {
std::cout << "catched...
2015 Jan 27
2
[LLVMdev] RFC: Native Windows C++ exception handling
...at will feed into an indirectbr terminator.
Similar to SjLj, SSA values live across the landing pad entrances and exits will be demoted to stack allocations. Unlike SjLj, to allow access from outlined landing pad code, the stack memory will be part of the @llvm.frameallocate block.
Here's how _Z4testv would look after preparation:
define void @_Z4testv() #0 {
entry:
%frame_alloc = call i8* @llvm.frameallocate(i32 2)
%capture_block = bitcast i8* %frame_alloc to %captures._Z4testv*
%outer = getelementptr %captures._Z4testv* %capture_block, i32 0, i32 0
%inner = getelementptr %captures._Z4...
2014 Oct 11
4
[LLVMdev] Optimization hints for "constant" loads
...ses. The problem is that any call can hide a
invariant.end intrinsic. As a result, the optimizer must conservatively
assume that any call clobbers the "invariant" location. This makes the
intrinsic a non-starter in it's current form.
; Function Attrs: uwtable
define zeroext i1 @_Z4testv() #0 {
%1 = tail call noalias i8* @_Znwm(i64 4) #3
%2 = bitcast i8* %1 to i32*
store i32 5, i32* %2, align 4, !tbaa !1
%discard = call {}* @llvm.invariant.start(i64 4, i8* %1)
tail call void @_Z6escapePi(i32* %2)
%3 = load i32* %2, align 4, !tbaa !1
%4 = icmp eq i32 %3, 5 <-...
2014 Sep 10
7
[LLVMdev] Optimization hints for "constant" loads
I'm looking at how to optimize IR which contains reads from a field
which is known to be initialized exactly once. I've got an idea on how
to approach this, but wanted to see if others have alternate ideas or
similar problems which might spark discussion. It feels like there's a
potentially generally useful optimization hint here if we can generalize
it sufficiently without