similar to: [LLVMdev] Incredible effects of extending AtomicSDNode::Ops

Hi all, The C++11 (& C11) compare_exchange functions with explicit memory order allow you to specify two sets of semantics, one for when the exchange actually happens and one for when it fails. Unfortunately, at the moment the LLVM IR "cmpxchg" instruction only has one ordering, which means we get sub-optimal codegen. This probably affects all architectures which use

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

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:

Nadav, I've been reading over the patches and I was wondering if you could elaborate your concerns here. I share your goal of reducing compilation time regressions for users that don't care about new feature X. From my very quick glance over the patches, I didn't see anything I couldn't opt out of. Maybe we can talk about specifics and figure out a way to make these changes not

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

I need a review of this patch and if it looks sane, someone to apply it to their local sources and run tests in Debug+Checks mode. The patch replaces the intrusive SDUse list with a std::list<> when XDEBUG is active. I believe I've maintained the semantics of the SDUse list but I need a double-check. The patch exposes all kinds of problems in Debug+Checks mode. Right now most of

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

SDUse's Prev and Next members implement a use list. Copying them probably wouldn't immediately break anything, but it wouldn't be meaningful. Dan On Feb 24, 2010, at 3:08 PM, David Greene wrote: > I just found a major bug in SelectionDAG. Well, I found it several weeks ago > and finally diagnosed it today. > > One possible fix comes down to holding SDUses about to be

I just found a major bug in SelectionDAG. Well, I found it several weeks ago and finally diagnosed it today. One possible fix comes down to holding SDUses about to be processed in a queue. But this would require the SDUse copy constructor to be public. Why is it private and unimplemented right now? What's the assumption that's trying to protect?

On Wednesday 24 February 2010 18:47:19 Dan Gohman wrote: > SDUse's Prev and Next members implement a use list. Copying them > probably wouldn't immediately break anything, but it wouldn't be > meaningful. I understand that the copied SDUse wouldn't be represented in the list, so I can understand the general reasons for making the copy constructor private. In this case,

On Thursday 25 February 2010 20:20:56 Dan Gohman wrote: Wrong thread? > SDUse::setInitial should initialize List to null in your patch. You're > probably seeing random uninitialized data noise without that. > (Though valgrind wouldn't notice this because of the aggressive reuse > of allocated memory.) Why isn't the default constructor called? I would have expected that

On Feb 25, 2010, at 2:24 PM, David Greene wrote: > On Thursday 25 February 2010 16:17:10 David Greene wrote: >> On Thursday 25 February 2010 16:07:59 Chris Lattner wrote: >>> On Feb 25, 2010, at 12:01 PM, David Greene wrote: >>>> I am seeing a whole lot of failures in the tests on trunk. From >>>> discussions with Chris and others, I should not be seeing

Just so this doesn't get lost in threads dealing with SelectionDAG issues, I'd like to post this patch for review. It changes the SDUse list from an intrusive list to a std::list<> under XDEBUG. This allows us to use the debugging features of the standard library to track down stubborn bugs. I've used this to diagnose in issue in SelectionDAG in our sources and also in the

Hi all, Attached is a sequence of patches that changes the IR to support more than two synchronization scopes. This is still a work in progress, and these patches are only meant to start a more detailed discussion on the way forward. One big issue is the absence of any backend that actually makes use of intermediate synchronization scopes. This work is meant to be just one part of the

Hi list, in our LLVM-based-project we are writing a backend for our processor. The architecture is a quite straight-forward RISC, but it does not have hardware interlocks, i.e. data hazards involving memory access must be resolved by the compiler, either by scheduling unrelated instructions or by inserting NOOPs into the load delay slots: ---- For example, code which looks like that: load

Are SDUses ever allowed to be part of more than one list? I would think not due to the intrusive nature of the list links. However, this is what I am seeing with some testcases on trunk. I am putting together a patch that shows these kinds of problems in XDEBUG mode. I'll post it ASAP. -Dave

On Feb 25, 2010, at 6:20 PM, Dan Gohman wrote: > > On Feb 25, 2010, at 2:24 PM, David Greene wrote: > >> On Thursday 25 February 2010 16:17:10 David Greene wrote: >>> On Thursday 25 February 2010 16:07:59 Chris Lattner wrote: >>>> On Feb 25, 2010, at 12:01 PM, David Greene wrote: >>>>> I am seeing a whole lot of failures in the tests on trunk.

Do you have a fix for the blackfin codegen? That would be a great way to motivate this patch. Otherwise, at a glance, it appears you fixed the issues I raised, so this is fine, if it catches real bugs. Dan On Mar 1, 2010, at 10:02 AM, David Greene wrote: > Just so this doesn't get lost in threads dealing with SelectionDAG > issues, I'd like to post this patch for review. It