Hi all,
This is a (very) rough patch to fix building LLVM with exceptions on
PPC Darwin. Basically, it puts the burden of adding the "--enable-eh"
on the specific target, which is where I think it should go.
If this is okay, then I can clean the patch up and submit it.
-bw
Index: gcc/llvm-backend.cpp
Hi Bill,
This is a (very) rough patch to fix building LLVM with exceptions on
PPC Darwin. Basically, it puts the burden of adding the "--enable-eh"
on the specific target, which is where I think it should go.
I don't like it. LLVM has plenty of features that are not supported
on all targets, why should it be the responsability of llvm-gcc to manage
this particular one and not the others? It is true that llvm-gcc is
currently the only producer of eh intrinsics. But hopefully this will
not always be the case; must all front-ends to LLVM manage -enable-eh?
If LLVM doesn't support exception handling for a target then -enable-eh
causes eh code to be lowered to nothing. It seems to me that problem with
x86-darwin is that LLVM thinks eh is supported but it isn't. Why not simply
set SupportsExceptionHandling to false for that target?
Ciao,
Duncan.
I agree with Duncan: can't the target (which knows the capabilities of the currently selected subtarget) set the value of SupportsExceptionHandling correctly?
-Chris
They do. However, it doesn't seem to stop it from failing during compilation of unwind-dw2.c for libgcc -- it has "__builtin_eh_return" in it. During 4-way FAT PPC compilation, it tries to compile this file and fails during the LowerOperation function. Turning --enable-eh off makes the error go away.
It may be my lack of understanding, but it appears that having --enable-eh set during compilation of llvm-gcc is causing extra files to be compiled. During bootstrapping, these files seem to rely upon having the EH stuff in place. That's why it's "special" w.r.t. the other features that aren't supported on all platforms.
Yes, it's ugly, and I don't like it either. I'm open to suggestions on what could be the cause of the failure I'm seeing with unwind-dw2.c, et al, other than EH support.
-bw
Hi Bill,
> I agree with Duncan: can't the target (which knows the capabilities
> of the currently selected subtarget) set the value of
> SupportsExceptionHandling correctly?
>
They do.
indeed SupportsExceptionHandling is set to false for all 64 bit
targets (that said, someone should test 32 bit x86-darwin).
However, it doesn't seem to stop it from failing during
compilation of unwind-dw2.c for libgcc -- it has
"__builtin_eh_return" in it. During 4-way FAT PPC compilation, it
tries to compile this file and fails during the LowerOperation
function. Turning --enable-eh off makes the error go away.
In LegalizeDAG, EH_RETURN should be lowered to nothing on a 64
bit target, see the logic in the "Legal" case. So it seems like
the "lower to nothing" logic is not working properly.
It may be my lack of understanding, but it appears that having --
enable-eh set during compilation of llvm-gcc is causing extra files
to be compiled.
No, it only effects LLVM codegen.
During bootstrapping, these files seem to rely upon
having the EH stuff in place. That's why it's "special" w.r.t. the
other features that aren't supported on all platforms.
No, when -enable-eh is turned off the LLVM eh_return intrinsic is
still generated. However it is lowered to nothing at the level of
SelectionDAGISel. If -enable-eh is turned on then a selection DAG
node is created for it, which is lowered to nothing at the level of
LegalizeDAG. There is clearly a bug in this last part.
Yes, it's ugly, and I don't like it either. I'm open to suggestions
on what could be the cause of the failure I'm seeing with unwind-
dw2.c, et al, other than EH support.
Please compile unwind-dw2.c to bytecode and send it in. That way
I will be able to reproduce the problem.
Ciao,
Duncan.
Hello, Bill
It may be my lack of understanding, but it appears that having --
enable-eh set during compilation of llvm-gcc is causing extra files
to be compiled.
Oh, no. They are always compiled.
They do. However, it doesn't seem to stop it from failing during
compilation of unwind-dw2.c for libgcc -- it has
"__builtin_eh_return" in it. During 4-way FAT PPC compilation, it
tries to compile this file and fails during the LowerOperation
function. Turning --enable-eh off makes the error go away.
Could you please send me .bc, which fails? I'll try to figure out, what
is going wrong.
Here's the attached .ll file. Please use -march=ppc and/or ppc64.
Thanks!
-bw
unwind-dw2.s.gz (19.2 KB)
The fix had problems on PPC64. Here's what bugpoint came up with:
; ModuleID = 'bugpoint-reduced-simplified.bc'
target datalayout = "E-p:64:64:64-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:32:64-f32:32:32-f64:32:64-
v64:64:64-v128:128:128-a0:0:64-f128:64:128"
target triple = "powerpc64-apple-darwin9"
%struct._Unwind_Context = type { [146 x i8*], i8*, i8*, i8*, %struct.dwarf_eh_bases, i64 }
%struct._Unwind_Exception = type { i64, void (i32, %struct._Unwind_Exception*)*, i64, i64
}
%struct.dwarf_eh_bases = type { i8*, i8*, i8* }
declare fastcc void @uw_init_context_1(%struct._Unwind_Context*, i8*, i8*)
declare i8* @llvm.eh.dwarf.cfa(i32)
define void @_Unwind_Resume(%struct._Unwind_Exception* %exc) {
entry:
call i8* @llvm.eh.dwarf.cfa( i32 0 ) ; <i8*>:0 [#uses=1]
call fastcc void @uw_init_context_1( %struct._Unwind_Context* null, i8* %0, i8* null )
ret void
}
-bw