similar to: [LLVMdev] exception handling broken on x86-64?

On Feb 9, 2008, at 2:48 PM, Anton Korobeynikov wrote: >> After comparing the generated assembler code with native gcc code I >> think the generated code is fine, just the exception handler info in >> the non-code sections is broken/missing. > It seems, that EH dwarf information emission is disabled in > X86TargetAsmInfo.cpp. Remove the is64Bit() condition near >

Where we are on the subject... Are we sure EH is done for x86? These two tests have never worked on Mac OS X / x86: SPEC/CINT2006/471.omnetpp Shootout-C++/except Evan On Feb 9, 2008, at 2:57 PM, Dale Johannesen wrote: > > On Feb 9, 2008, at 2:48 PM, Anton Korobeynikov wrote: >>> After comparing the generated assembler code with native gcc code I >>> think the generated

ola, ive been looking at adding support for an -msave-args option for use on x86_64. the short explanation of it is that it makes x86_64 function prologues store their register arguments on the stack. the purpose of this is to make the arguments trivially accessible for things like stack traces with arguments. as per https://blogs.oracle.com/sherrym/entry/obtaining_function_arguments_on_amd64,

Hi Evan, I incoporated the changes you request but to the following i have got a question: > Also, moving the option > there will allow us to change fastcc ABI (callee popping arguments) > only when this option is on. See Chris' email: I am not to sure on that. because that would make modules compiled with the flag on incompatible with ones compiled without the flag off as

Hi all, The current repository (revision 56968.) does not compile on my Linux box (with GCC 3.4.6): X86TargetAsmInfo.cpp:41: error: duplicate explicit instantiation of `bool llvm::X86TargetAsmInfo<BaseTAI>::ExpandInlineAsm(llvm::CallInst*) const [with BaseTAI = llvm::TargetAsmInfo]' X86TargetAsmInfo.cpp:43: error: duplicate explicit instantiation of `bool

Here you go: Starting program: /home/chandlerc/code/compilers/build/llvm-gcc/gcc/cc1 -fpreprocessed -march=k8 testcase.i -o /dev/null warning: no loadable sections found in added symbol-file system-supplied DSO at 0x7fff0d5fe000 [Thread debugging using libthread_db enabled] foocc1: /home/chandlerc/code/compilers/llvm-gcc/gcc/llvm-types.cpp:81: const llvm::Type* llvm_set_type(tree_node*, const

Does this fix it? Index: lib/Target/X86/X86Subtarget.h =================================================================== --- lib/Target/X86/X86Subtarget.h (revision 48879) +++ lib/Target/X86/X86Subtarget.h (working copy) @@ -144,9 +144,12 @@ std::string getDataLayout() const { const char *p; - if (is64Bit()) - p = "e-p:64:64-s:64-f64:64:64-i64:64:64-f80:128:128"; -

Probably better to move the discussion to a bug? Evan On Mar 27, 2008, at 9:04 AM, Duncan Sands wrote: > Does this fix it? > > Index: lib/Target/X86/X86Subtarget.h > =================================================================== > --- lib/Target/X86/X86Subtarget.h (revision 48879) > +++ lib/Target/X86/X86Subtarget.h (working copy) > @@ -144,9 +144,12 @@ > >

On Mon, Feb 23, 2009 at 12:12 AM, Aaron Gray < aaronngray.lists at googlemail.com> wrote: > On Sun, Feb 22, 2009 at 11:15 PM, Anton Korobeynikov < > anton at korobeynikov.info> wrote: > >> >> Actually its [configure-stage3-intl] where its hanging. >> >> This can easily be due to inline FP math in the stdlib headers. For >> example - I had to

Comments: CheckDAGForTailCallsAndFixThem - 1. for (SelectionDAG::allnodes_iterator BE = DAG.allnodes_begin(), + BI = prior(DAG.allnodes_end()); BI != BE; BI--) { Please use pre-decrement instead of post-decrement. 2. The function is slower than it should be. You are scanning all the nodes in the DAG twice. You should just examine DAG.getRoot() to make determine whether it's a

Not sure who owns this bit of code, so sending this to the general list. It looks like there may be an unintentional fall through happening in the X86RegisterInfo::getCallPreservedMask function. http://llvm.org/docs/doxygen/html/X86RegisterInfo_8cpp_source.html case CallingConv::Intel_OCL_BI

Hi all, As previously mentioned on this list the Haskell compiler GHC has a new LLVM based back-end. The back-end needs a new calling convention to efficiently use LLVM and that is what this patch does, just for X86 at the moment. Breakdown: 1) Need actual calling convention Touches: - include/llvm/CallingConv.h - lib/Target/X86/X86CallingConv.td 2) Handling new calling

On Oct 5, 2007, at 2:42 AM, Arnold Schwaighofer wrote: > Hi Evan, > I incoporated the changes you request but to the following i have got > a question: > >> Also, moving the option >> there will allow us to change fastcc ABI (callee popping arguments) >> only when this option is on. See Chris' email: > > I am not to sure on that. because that would make

On Mar 2, 2010, at 5:33 PM, David Terei wrote: > Hi all, > > As previously mentioned on this list the Haskell compiler GHC has a new LLVM based back-end. The back-end needs a new calling convention to efficiently use LLVM and that is what this patch does, just for X86 at the moment. Nice, > The GHC developers would love to get this included in LLVM so that we don't need to

OK, new patch attached. Hopefully in time for 2.7. Chris Lattner wrote: > 1) is the GHC calling conv intended to be target specific? If it is x86 specific, it should get an X86 prefix. If not, it should move up to be #10 after Cold. No its intended to be supported on any platforms that GHC is supported on, which is just x86 and SPARC at the moment. At the moment I've just done X86, will

Hey Evan, At the point of the instructions you suggested I step through, X86ISelLowering has this state: - this 0x00000000005fe728 {VarArgsFrameIndex=-842150451 RegSaveFrameIndex=-842150451 VarArgsGPOffset=3452816845 ...} llvm::X86TargetLowering * const + llvm::TargetLowering {TM={...} TD=0x00000000008edac0

On Feb 12, 2008, at 5:26 PM, Chuck Rose III wrote: > Hola LLVMers, > > I’m debugging through some strangeness that I’m seeing on X64 on > windows with LLVM2.2. I had to change the code so that it would > engage the x64 target machine on windows builds, but I’ve otherwise > left LLVM 2.2 alone. The basic idea is that I’ve got a function bar > which is compiled by

It seems that the || should be && here? /// IsLegalToCallImmediateAddr - Return true if the subtarget allows calls /// to immediate address. bool X86Subtarget::IsLegalToCallImmediateAddr(const TargetMachine &TM) const { if (Is64Bit) return false; return isTargetELF() || TM.getRelocationModel() == Reloc::Static; } For example, if you are doing ELF PIC (i.e. for a shared

I got bit by this in LLVM 2.4 DagCombiner.cpp and it's still in trunk: SDValue DAGCombiner::visitSTORE(SDNode *N) { [...] // If this is a store of a bit convert, store the input value if the // resultant store does not need a higher alignment than the original. if (Value.getOpcode() == ISD::BIT_CONVERT && !ST->isTruncatingStore() && ST->isUnindexed()) {

Hola LLVMers, I'm debugging through some strangeness that I'm seeing on X64 on windows with LLVM2.2. I had to change the code so that it would engage the x64 target machine on windows builds, but I've otherwise left LLVM 2.2 alone. The basic idea is that I've got a function bar which is compiled by VStudio and I'm creating another function foo via LLVM JIT which is going