similar to: [LLVMdev] r114523 (convert the last 4 X86ISD...) breaks clang

I will take a look in the next couple hours. Feel free to revert it in the meantime, thanks! -Chris On Sep 22, 2010, at 1:53 AM, Jean-Daniel Dupas <devlists at shadowlab.org> wrote: > Hello, > > After commit r114523, I start to get crash when compiling with clang (Release+Asserts) for i386: > (I know I should fill a bug report instead of posting here, but I don't get

Right now the MemSDNode keeps a volatile bit in the SubclassData to mark volatile memory operations. We have some changes we'd like to push back that adds a NonTemporal flag to MemSDNode to mark instructions where movnt (on x86) and other goodness can happen (we'll also add the TableGen patterns to properly select movnt). In our tree we simply added another flag to the MemSDNode

> -----Original Message----- > From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] > On Behalf Of Duncan Sands > Sent: Thursday, March 31, 2011 7:43 PM > To: llvmdev at cs.uiuc.edu > Subject: Re: [LLVMdev] Assert in VerifySDNode > > Hi Micah, > > > assert(!isa<MemSDNode>(N) && "Bad MemSDNode!"); > > you

We are syncing to 2.9 and we are hitting an with our backend in VerifySDNode in SelectionDAG.cpp. The first assert here is failing assert(!isa<MemSDNode>(N) && "Bad MemSDNode!"); Now, this is new to 2.9 and I am trying to understand what is invalid about what I am generating. What I generate has worked fine from LLVM version 2.4 until now without causing any issues.

Hi All, I'd like to add HLE support in LLVM/clang consistent to GCC's style [1]. HLE from Intel TSX [2] is legacy compatible instruction set extension to specify transactional region by adding XACQUIRE and XRELEASE prefixes. To support that, GCC chooses the approach by extending the memory order flag in __atomic_* builtins with target-specific memory model in high bits (bit 31-16 for

Hi Micah, > assert(!isa<MemSDNode>(N) && "Bad MemSDNode!"); you can't use getNode to allocate a MemSDNode because it does not allocate enough memory (MemSDNode has extra fields beyond the operands). Ciao, Duncan.

Hi Bryan, thanks for your kind reply but it happend only with some fonts not all font file, (email with attachment is under verification by admin, so i resend this without attachment file) here i attach 2 screenshot one original folder and second backup folder, you can notice that the font .otf, .ttf, .dfont have no problem in rsync it copied as it is but the font that not show extension (Font

Hi All, I'd like to add HLE support in LLVM/clang consistent to GCC's style [1]. HLE from Intel TSX [2] is legacy compatible instruction set extension to specify transactional region by adding XACQUIRE and XRELEASE prefixes. To support that, GCC chooses the approach by extending the memory order flag in __atomic_* builtins with target-specific memory model in high bits (bit 31-16 for

Here is the patch 0004-Enable-HLE-code-generation.patch Yours - Michael On Tue, 2013-02-19 at 14:07 -0800, Michael Liao wrote: > Hi All, > > I'd like to add HLE support in LLVM/clang consistent to GCC's style [1]. > HLE from Intel TSX [2] is legacy compatible instruction set extension to > specify transactional region by adding XACQUIRE and XRELEASE prefixes. > To

Here is the patch 0002-Add-HLE-target-feature.patch Yours - Michael On Tue, 2013-02-19 at 14:07 -0800, Michael Liao wrote: > Hi All, > > I'd like to add HLE support in LLVM/clang consistent to GCC's style [1]. > HLE from Intel TSX [2] is legacy compatible instruction set extension to > specify transactional region by adding XACQUIRE and XRELEASE prefixes. > To support

Here is the patch 0003-Add-XACQ-XREL-prefix-and-encoding-asm-printer-suppor.patch Yours - Michael On Tue, 2013-02-19 at 14:07 -0800, Michael Liao wrote: > Hi All, > > I'd like to add HLE support in LLVM/clang consistent to GCC's style [1]. > HLE from Intel TSX [2] is legacy compatible instruction set extension to > specify transactional region by adding XACQUIRE and

On Jul 31, 2009, at 11:26 AM, David Greene wrote: > Right now the MemSDNode keeps a volatile bit in the SubclassData to > mark > volatile memory operations. > > We have some changes we'd like to push back that adds a NonTemporal > flag > to MemSDNode to mark instructions where movnt (on x86) and other > goodness > can happen (we'll also add the TableGen

Hi Michael, Why do you want to add transactional memory support to LLVM ? Can't you implement transactional memory using a library call ? Judging by the number of patches it looks like a major change to LLVM, and I am not sure that I understand the motivation for including it in LLVM. Thanks, Nadav On Feb 19, 2013, at 11:52 AM, Michael Liao <michael.liao at intel.com> wrote:

I want to get some clarification on the exact semantics of the MachineMemOperand attached to memory-touching instructions. From what I understand, a MemSDNode has an associated MachineMemOperand and a MachineInstr can have zero or more attached MachineMemOperands. But what is the guarantee/constraint placed on optimization/codegen passes for maintaining the contents of a MachineMemOperand? In

Hello everyone! I have a PowerMac running 10.6.8 and I'd love to get it connected to my VPN. However, even by compiling tuntaposx by hand on the said MacPro, I see that the kernel module is apparently built for x86_64 systems: macintosh MacOS ?? pwd /Library/Extensions/tun.kext/Contents/MacOS macintosh MacOS ?? file tun tun: Mach-O 64-bit kext bundle x86_64 Because YES! The system is

On Saturday 01 August 2009 15:12, Dan Gohman wrote: > LoadSDNode, which inherits from MemSDNode is the largest > SDNode. With the current SDNode allocation strategy, making it > bigger will increase the allocation needed for all nodes. Ok. > > new (N) LoadSDNode(..., isVolatile|isNonTemporal); > > > > Thoughts? > > This sounds reasonable. I'd suggest

On Feb 11, 2010, at 12:07 PM, David Greene wrote: > On Thursday 11 February 2010 14:02:13 Dan Gohman wrote: > >>>> Putting a bit (or multiple bits) in MachineMemOperand for this >>>> would also make sense. >>> >>> Is there any chance a MachineMemOperand will be shared by multiple >>> instructions? >> >> Yes. > > Then

On Thursday 11 February 2010 14:44:23 Dan Gohman wrote: > > Then we can't use it to hold a non-temporal flag. The operand might be > > non-temporal in one context but it may not be in another. > > Sharing only happens when two instructions have the "same" memory > reference info. You just need to make sure that the non-temporal > flag is significant.

I finally got around to testing this on a Bloomfield processor (Early 2009 MacPro 2x2.66 GHz dual-quad core) and the regressions from http://llvm.org/bugs/show_bug.cgi?id=22589 are even more severe. For 10 runs of scimark2_1c built with "-O3 -march=native"... llvm 3.5.1 1204.16+/-2.66 Mflops 3.6 branch 866.49+/-1.26 Mflops Do you seriously want to ship with a 39% performance

Hello. I fixed the bug reported in the previous post on this thread (<<llvm::MemSDNode::MemSDNode(unsigned int, unsigned int, const llvm::DebugLoc&, llvm::SDVTList, llvm::EVT, llvm::MachineMemOperand*): Assertion `memvt.getStoreSize() <= MMO->getSize() && "Size mismatch!"' failed.>>) The problem with this strange error reported comes from