jfb (JF Bastien)
User

Projects

User does not belong to any projects.

User Details

User Since
Jan 27 2014, 9:36 AM (190 w, 4 d)

Recent Activity

Jun 28 2017

jfb accepted D34806: [MergeFunctions] Merge small functions if possible without a thunk.

A few questions, but this looks good.

Jun 28 2017, 9:49 PM
jfb accepted D34802: [MergeFunctions] Remove alias support.
Jun 28 2017, 9:21 PM

Apr 20 2017

jfb added a comment to D32265: Add __CLANG_ATOMIC_<TYPE>_LOCK_FREE macros for use in MSVC compatibility mode..

It looks like Billy is going to do something somewhat similar when he rewrites it: https://twitter.com/jfbastien/status/855168230918307840
For now it's kinda #define IS_LOCK_FREE ¯\_(ツ)_/¯

Apr 20 2017, 2:23 PM
jfb added a comment to D32265: Add __CLANG_ATOMIC_<TYPE>_LOCK_FREE macros for use in MSVC compatibility mode..
In D32265#731709, @jfb wrote:

Is it a goal to support Microsoft's STL with this? If so, how does MSVC's STL implement is_always_lock_free at the moment? CL 19 2017 RTW doesn't seem to have anything? Presumably they'll have to do *something*.

The goal is to allow libc++ to implement`ATOMIC_<TYPE>_LOCK_FREE` on Windows using Clang. As you know libc++ currently uses the __GCC_ATOMIC_FOO macros, but those aren't available on Windows.

Apr 20 2017, 2:15 PM
jfb added a comment to D32265: Add __CLANG_ATOMIC_<TYPE>_LOCK_FREE macros for use in MSVC compatibility mode..

Is it a goal to support Microsoft's STL with this? If so, how does MSVC's STL implement is_always_lock_free at the moment? CL 19 2017 RTW doesn't seem to have anything? Presumably they'll have to do *something*.

Apr 20 2017, 1:26 AM

Aug 10 2016

jfb added a comment to D22711: Diagnose invalid failure memory orderings..

Warnings look correct. Could they be made more useful by suggesting that acq_rel be acquire instead, and release be relaxed instead?

Aug 10 2016, 5:31 PM

Aug 3 2016

jfb added a comment to D23041: Un-XFAIL GCC atomics.align.

I wrote a quick test, and I think this is technically OK for x86 because alignment "Just Works", but I think it's borked on GCC+ARM (I don't have a system to test that here): https://github.com/jfbastien/atomic_nullptr/blob/master/atomic_nullptr.cc

Aug 3 2016, 2:54 PM
jfb added a comment to D23041: Un-XFAIL GCC atomics.align.

@EricWF ran this on configuration cxx_under_test=g++-4.9. It generates the following error:

libcxx/test/libcxx/atomics/atomics.align/align.pass.sh.cpp:32: atomic_test<T>::atomic_test() [with T = std::nullptr_t]: Assertion `alignof(this->__a_) >= sizeof(this->__a_) && "expected natural alignment for lock-free type"' failed.

I think GCC is broken. See the following (semi-relevant) test: https://godbolt.org/g/pFUqVY
That's not quite what I'm testing (this used libstdc++ and looks at std::atomic, not the value contained), but I'd nonetheless expect the std::atomic container to be sufficiently aligned.

Aug 3 2016, 1:43 PM

Aug 1 2016

jfb retitled D23041: Un-XFAIL GCC atomics.align from to Un-XFAIL GCC atomics.align.
Aug 1 2016, 5:16 PM
jfb committed rL277404: NFC: fix typo.
NFC: fix typo
Aug 1 2016, 4:42 PM
jfb committed rL277380: atomics.align: XFAIL GCC.
atomics.align: XFAIL GCC
Aug 1 2016, 1:36 PM
jfb committed rL277368: libc++: test lock-free atomic alignment.
libc++: test lock-free atomic alignment
Aug 1 2016, 12:34 PM
jfb closed D22073: libc++: test lock-free atomic alignment by committing rL277368: libc++: test lock-free atomic alignment.
Aug 1 2016, 12:34 PM
jfb added a comment to D22073: libc++: test lock-free atomic alignment.

OK, IMO the way to handle this test is to have it manually link -latomic. This can be done by renaming the test to <test>.sh.cpp and adding the following lines:

// REQUIRES: libatomic
// RUN: %build -latomic
// RUN: %run

After that this LGTM.

Aug 1 2016, 11:25 AM
jfb updated the diff for D22073: libc++: test lock-free atomic alignment.
  • Move atomics.align to libcxx-specific
  • Give names to anonymous structs
  • Rename test, use REQUIRES / RUN commands
Aug 1 2016, 11:24 AM

Jul 22 2016

jfb added inline comments to D22557: [libcxx] Diagnose invalid memory order arguments in <atomic>. Fixes PR21179..
Jul 22 2016, 4:31 PM

Jul 21 2016

jfb committed rL276309: Remove FIXME for feature test macro.
Remove FIXME for feature test macro
Jul 21 2016, 10:41 AM
jfb added a comment to D22557: [libcxx] Diagnose invalid memory order arguments in <atomic>. Fixes PR21179..

Two comments, then lgtm.

Jul 21 2016, 10:38 AM

Jul 20 2016

jfb added inline comments to D22557: [libcxx] Diagnose invalid memory order arguments in <atomic>. Fixes PR21179..
Jul 20 2016, 3:46 PM
jfb added a comment to D22557: [libcxx] Diagnose invalid memory order arguments in <atomic>. Fixes PR21179..

Awesome, thanks for doing this!

Jul 20 2016, 11:40 AM

Jul 18 2016

jfb added a comment to D22385: [LoopReroll] Reroll loops with unordered atomic memory accesses.

Does this work when there's a fence in the middle of the loop?

Jul 18 2016, 5:05 PM

Jul 14 2016

jfb added a comment to D22326: [JumpThreading] PRE unordered loads.

Could you test that:

Jul 14 2016, 11:11 AM

Jul 13 2016

jfb added a comment to D22318: [MI] Fix MachineInstr::isInvariantLoad..

lgtm after the facts. ty!

Jul 13 2016, 4:26 PM

Jul 12 2016

jfb committed rL275210: libc++: name anonymous structs.
libc++: name anonymous structs
Jul 12 2016, 1:22 PM
jfb added a comment to D22073: libc++: test lock-free atomic alignment.
  • The test should be moved to test/libcxx/atomics/atomics.align since it's libc++ specific.
Jul 12 2016, 1:17 PM
jfb updated the diff for D22073: libc++: test lock-free atomic alignment.
  • Move atomics.align to libcxx-specific
  • Give names to anonymous structs
Jul 12 2016, 1:13 PM

Jul 11 2016

jfb updated subscribers of D21768: Support CFI for WebAssembly target.
Jul 11 2016, 1:50 PM
jfb added inline comments to D21768: Support CFI for WebAssembly target.
Jul 11 2016, 1:49 PM

Jul 7 2016

jfb updated subscribers of D22051: MergeSimilarFunctions: a code size pass to merge functions with small differences.
In D22051#476003, @jfb wrote:

Could you detail how this is different from MergeFunc, and what it would take to add the new capabilities to MergeFunc instead of duplicating?

The main difference is that the in-tree MergeFunctions can only merge identical functions (modulo pointer types) whereas MergeSimilarFunctions is also capable of merging sets of functions that are merely similar, i.e. have some differences in their instructions. This expands the scope of the optimization significantly.

Jul 7 2016, 3:49 PM
jfb accepted D22001: [DSE] Remove dead stores in end blocks containing fence.

lgtm

Jul 7 2016, 12:40 PM
jfb added a comment to D22001: [DSE] Remove dead stores in end blocks containing fence.

I'm not sure I understand the mentions of end block. Why is this relevant? A dead store is dead, regardless of successors. Could you explain?

Jul 7 2016, 10:23 AM

Jul 6 2016

jfb updated D22073: libc++: test lock-free atomic alignment.
Jul 6 2016, 4:47 PM
jfb updated subscribers of D22073: libc++: test lock-free atomic alignment.
Jul 6 2016, 4:46 PM
jfb retitled D22073: libc++: test lock-free atomic alignment from to libc++: test lock-free atomic alignment.
Jul 6 2016, 4:45 PM
jfb added a comment to D22051: MergeSimilarFunctions: a code size pass to merge functions with small differences.

Could you detail how this is different from MergeFunc, and what it would take to add the new capabilities to MergeFunc instead of duplicating?

Jul 6 2016, 2:42 PM

Jun 29 2016

jfb added a comment to D21124: Cache aware Loop Cost Analysis.

Quick review, nothing technical.

Jun 29 2016, 4:09 PM
jfb added inline comments to D21808: [WebAssembly] Handle debug information and virtual registers without crashing.
Jun 29 2016, 2:37 PM
jfb added inline comments to D21768: Support CFI for WebAssembly target.
Jun 29 2016, 10:37 AM
jfb added a comment to D21808: [WebAssembly] Handle debug information and virtual registers without crashing.

The examples are pretty wordy, could you trim them so they have less code while preserving the same checks?

Jun 29 2016, 10:14 AM
jfb added a comment to D21808: [WebAssembly] Handle debug information and virtual registers without crashing.

The examples are pretty wordy, could you trim them so they have less code while preserving the same checks?

Jun 29 2016, 10:14 AM

Jun 27 2016

jfb added a comment to D21768: Support CFI for WebAssembly target.

I'd like to see a few .ll tests as well.

Jun 27 2016, 3:19 PM

May 10 2016

jfb accepted D19275: Do not register incompatible C++ destructors with __cxa_atexit.

lgtm

May 10 2016, 9:29 AM

May 5 2016

jfb added inline comments to D19105: Changes in clang after running http://reviews.llvm.org/D18821.
May 5 2016, 12:36 PM

Apr 27 2016

jfb added a comment to D14327: Add llvm.ldexp.* intrinsic, associated SDNode and library calls.

Regarding errno: it's totally valid to ignore if the implementation sets math_errhandling & MATH_ERRNO to zero. Of course, you need to know the C library to make that choice, but its value never changes at runtime. See C11 section 7.12, as well as the soon-to-be-published C++ paper p0108r1 which you can preview here.

Apr 27 2016, 3:18 PM
jfb updated subscribers of D19275: Do not register incompatible C++ destructors with __cxa_atexit.

I guess there's a more general issue here which is that LLVM appears to be more permissive about prototype mismatch than wasm. Specifically, I'm thinking about how swifterror relies on being able to pass extra parameters to a function that doesn't expect them and not get UB. I guess as long as LLVM doesn't introduce any prototype mismatch during optimization, that's OK, but this seems like it would be a real problem if we ever wanted to port swift to wasm.

Apr 27 2016, 10:44 AM
jfb added a comment to D19275: Do not register incompatible C++ destructors with __cxa_atexit.

@t.p.northover: would an acceptable solution be to add a new trait such as CGM.getCXXABI().CanCallMismatchedFunctionType() or something of the sort? ARM would set it to true, wasm to false.

Apr 27 2016, 10:21 AM

Apr 25 2016

jfb added inline comments to D19440: [GVN] Do local FRE for unordered atomic loads.
Apr 25 2016, 8:45 AM

Apr 22 2016

jfb added a comment to D19381: Extend load/store type canonicalization to handle unordered operations.

This landed as 267210.

@JF - There shouldn't be any code generation differences for two types with the same alignment, even if that alignment isn't natural.

Apr 22 2016, 2:19 PM

Apr 21 2016

jfb added a comment to D19381: Extend load/store type canonicalization to handle unordered operations.

Forgot to say: lgtm after these comments.

Apr 21 2016, 1:10 PM
jfb added a comment to D19381: Extend load/store type canonicalization to handle unordered operations.

I don't think it matters but would rather ask: there's no case where a less-than-naturally-aligned atomic would matter? I'm specifically thinking of an example such as:

%v = load atomic i32, i32* %p unordered, align 2
%c = bitcast i32 to float
%s = add float %c, 1.0

Could this new code be leading backends to generate bad code? I think not, LMK if you think otherwise.

Apr 21 2016, 1:10 PM
jfb committed rL267039: NFC: fix copy / paste comment.
NFC: fix copy / paste comment
Apr 21 2016, 12:59 PM
jfb committed rL267036: NFC: fix nonsensical comment.
NFC: fix nonsensical comment
Apr 21 2016, 12:47 PM

Apr 20 2016

jfb added a comment to D19075: mergefunc: avoid merge with loop metadata.
In D19075#406978, @jfb wrote:
In D19075#406955, @jfb wrote:
In D19075#406897, @jfb wrote:

Do we not unqiue MDNodes? This seems like a lot of code for what I would have thought should be: Compare the pointer equality all MDNode operands except the first (because the first is the unique loop id).

mergefunc wants an ordering for what it compares, so pure equality isn't sufficient (although cmpLoopOperandMetadata does start with L == R). It needs to know how to order in a stable way, so we also can't just order based on pointer value.

Do you not already have a way to do this for metadata in general?

Not that I know, but I've been wrong before! I think a lot of the logic in mergefunc could be moved to the actual instruction (ordering as well as mergefunc's special hashing) and factored in a way that would reduce the risk of breakage (right now mergefunc breaks if not updated in sync).

This synchronization requirement is part of what worries me about embedding so much knowledge of the metadata format in this code.

I need to hack on things a bit more before I feel comfortable enough to propose a clean solution.

Okay. I suspect a general solution for metadata can be used here (minus the first operand for loop ids), once such a thing exists.

Are you saying the current patch looks good with promise to generalize solution later, or are you asking for the generalized solution first?

I'm asking for the general solution first, specifically because it seems like it would be simpler than the current code, and more general. I really don't want to embed specific knowledge of the format of the loop metadata into this pass if not really necessary.

Apr 20 2016, 1:53 PM
jfb added a comment to D19075: mergefunc: avoid merge with loop metadata.
In D19075#406955, @jfb wrote:
In D19075#406897, @jfb wrote:

Do we not unqiue MDNodes? This seems like a lot of code for what I would have thought should be: Compare the pointer equality all MDNode operands except the first (because the first is the unique loop id).

mergefunc wants an ordering for what it compares, so pure equality isn't sufficient (although cmpLoopOperandMetadata does start with L == R). It needs to know how to order in a stable way, so we also can't just order based on pointer value.

Do you not already have a way to do this for metadata in general?

Not that I know, but I've been wrong before! I think a lot of the logic in mergefunc could be moved to the actual instruction (ordering as well as mergefunc's special hashing) and factored in a way that would reduce the risk of breakage (right now mergefunc breaks if not updated in sync).

This synchronization requirement is part of what worries me about embedding so much knowledge of the metadata format in this code.

I need to hack on things a bit more before I feel comfortable enough to propose a clean solution.

Okay. I suspect a general solution for metadata can be used here (minus the first operand for loop ids), once such a thing exists.

Apr 20 2016, 1:43 PM
jfb added a comment to D19075: mergefunc: avoid merge with loop metadata.
In D19075#406897, @jfb wrote:

Do we not unqiue MDNodes? This seems like a lot of code for what I would have thought should be: Compare the pointer equality all MDNode operands except the first (because the first is the unique loop id).

mergefunc wants an ordering for what it compares, so pure equality isn't sufficient (although cmpLoopOperandMetadata does start with L == R). It needs to know how to order in a stable way, so we also can't just order based on pointer value.

Do you not already have a way to do this for metadata in general?

Apr 20 2016, 1:22 PM
jfb added a comment to D19075: mergefunc: avoid merge with loop metadata.

Do we not unqiue MDNodes? This seems like a lot of code for what I would have thought should be: Compare the pointer equality all MDNode operands except the first (because the first is the unique loop id).

Apr 20 2016, 12:51 PM

Apr 19 2016

jfb added a comment to D19275: Do not register incompatible C++ destructors with __cxa_atexit.

lgtm besides two nits. Would be good to get a review from @t.p.northover or someone from ARM.

Apr 19 2016, 2:55 PM
jfb added inline comments to D19275: Do not register incompatible C++ destructors with __cxa_atexit.
Apr 19 2016, 2:24 PM
jfb updated subscribers of D19275: Do not register incompatible C++ destructors with __cxa_atexit.
Apr 19 2016, 11:26 AM
jfb added inline comments to D19275: Do not register incompatible C++ destructors with __cxa_atexit.
Apr 19 2016, 11:25 AM

Apr 18 2016

jfb committed rL266641: NFC: unify clang / LLVM atomic ordering.
NFC: unify clang / LLVM atomic ordering
Apr 18 2016, 11:07 AM
jfb committed rL266640: NFC: unify clang / LLVM atomic ordering.
NFC: unify clang / LLVM atomic ordering
Apr 18 2016, 11:07 AM
jfb committed rL266627: Lanai: fix debug build.
Lanai: fix debug build
Apr 18 2016, 9:39 AM
jfb added a comment to D19075: mergefunc: avoid merge with loop metadata.

Ping.

Apr 18 2016, 9:01 AM

Apr 17 2016

jfb committed rL266576: Revert "NFC: unify clang / LLVM atomic ordering".
Revert "NFC: unify clang / LLVM atomic ordering"
Apr 17 2016, 2:34 PM
jfb committed rL266575: Revert "NFC: unify clang / LLVM atomic ordering".
Revert "NFC: unify clang / LLVM atomic ordering"
Apr 17 2016, 2:34 PM
jfb committed rL266574: NFC: unify clang / LLVM atomic ordering.
NFC: unify clang / LLVM atomic ordering
Apr 17 2016, 2:06 PM
jfb committed rL266573: NFC: unify clang / LLVM atomic ordering.
NFC: unify clang / LLVM atomic ordering
Apr 17 2016, 2:06 PM
jfb closed D18876: NFC: unify clang / LLVM atomic ordering by committing rL266574: NFC: unify clang / LLVM atomic ordering.
Apr 17 2016, 2:06 PM
jfb closed D18875: NFC: unify clang / LLVM atomic ordering by committing rL266573: NFC: unify clang / LLVM atomic ordering.
Apr 17 2016, 2:06 PM

Apr 15 2016

jfb added a comment to D18876: NFC: unify clang / LLVM atomic ordering.
In D18876#402855, @jfb wrote:

The large amount of casting to/from integers for AtomicOrderingCABI makes me think that it probably ought not actually be converted to an enum class after all.

Untrusted user input with enums is a problem: you have to range-check before casting the int to the enum, with or without enum class, otherwise out-of-range is UB. I like it being explicit, but yeah what I had was wordy so I factored out the check.

Casting *out* of the enum to generate constants is also wordy, but I think that's also fine. We could add a version of ConstantInt which takes in is_integral_or_enum but that seems like a lot of work for little typing? I'm happy to do that if you think it's worthwhile.

Well, my suggestion had been to just leave it as a non-enum-class, like it was before -- with no casts to or from the enum type. I think the code as it was before was actually safe, too, wasn't it?

I'm just not really sure using strong enums for the CABI type is really buying much, since the basically only point of the C ABI kind is to use it as an integer. Essentially every uses of it will be converting to/from integers, won't it?

Apr 15 2016, 4:47 PM
jfb added a comment to D18876: NFC: unify clang / LLVM atomic ordering.

The large amount of casting to/from integers for AtomicOrderingCABI makes me think that it probably ought not actually be converted to an enum class after all.

Apr 15 2016, 1:07 PM
jfb updated the diff for D18876: NFC: unify clang / LLVM atomic ordering.
  • Use validity checks, reduce casting while still avoiding UB on out-of-range enum values.
Apr 15 2016, 12:21 PM
jfb updated the diff for D18875: NFC: unify clang / LLVM atomic ordering.
  • Add validity check for conversions.
Apr 15 2016, 12:20 PM
jfb updated the diff for D18875: NFC: unify clang / LLVM atomic ordering.
  • Update AtomicExpandPass
Apr 15 2016, 9:04 AM

Apr 13 2016

jfb retitled D19075: mergefunc: avoid merge with loop metadata from to mergefunc: avoid merge with loop metadata.
Apr 13 2016, 2:26 PM
jfb committed rL266247: NFC mergefunc: const correctness.
NFC mergefunc: const correctness
Apr 13 2016, 2:17 PM

Apr 12 2016

jfb committed rL266128: NFC: MergeFunctions return early.
NFC: MergeFunctions return early
Apr 12 2016, 2:28 PM
jfb committed rL266124: NFC: MergeFunctions update more comments.
NFC: MergeFunctions update more comments
Apr 12 2016, 2:18 PM
jfb committed rL266112: Delete mergefunctions.clang.svn.patch.
Delete mergefunctions.clang.svn.patch
Apr 12 2016, 12:50 PM
jfb committed rL266099: Check alloca's special state.
Check alloca's special state
Apr 12 2016, 11:12 AM

Apr 11 2016

jfb committed rL266022: MergeFunctions: test alloca better.
MergeFunctions: test alloca better
Apr 11 2016, 5:09 PM
jfb committed rL266016: AtomicExpandPass: mark assert variable as used.
AtomicExpandPass: mark assert variable as used
Apr 11 2016, 4:09 PM
jfb added a comment to D18200: Add __atomic_* lowering to AtomicExpandPass..

Looks like this broke the build:

Apr 11 2016, 3:41 PM
jfb committed rL266007: NFC: keep comment up to date.
NFC: keep comment up to date
Apr 11 2016, 3:36 PM
jfb added inline comments to D18875: NFC: unify clang / LLVM atomic ordering.
Apr 11 2016, 1:03 PM
jfb accepted D18200: Add __atomic_* lowering to AtomicExpandPass..

Forgot to say: I talked to @reames in person last week and he said he was OK moving forward with this for now.

Apr 11 2016, 8:29 AM

Apr 9 2016

jfb added a comment to D18938: is_integral_or_enum ❥ enum class ⇒ hashable enum class.
In D18938#396391, @jfb wrote:
In D18938#396373, @jfb wrote:

I know these are all just hash values, so who cares, but in practice, you
may just want to use an explicit cast to std::underlying_type instead of
uint64_t.

I was being a bit lazy because the signature is hash_code hash_integer_value(uint64_t value), but you're right using underlying_type is probably better if hash_integer_value's input type were to change.

Fixed that.

Well that was slightly broken, but not locally. I did a quick fix for the bots in http://reviews.llvm.org/rL265880, will ponder a yet-more-correct one.

Apr 9 2016, 2:11 PM
jfb added a comment to D18938: is_integral_or_enum ❥ enum class ⇒ hashable enum class.
In D18938#396373, @jfb wrote:

This looks better than the hackery i came up with, so LGTM :)

One nit in case we want to care:

+ return ::llvm::hashing::detail::hash_integer_value((uint64_t)value);

So, you are guaranteed this value is either an enum, *or* convertible to
unsigned long long.

But what is the enum is not an unsigned type?

IE will this not still trigger on:

enum class e2: int {};

?

I know these are all just hash values, so who cares, but in practice, you
may just want to use an explicit cast to std::underlying_type instead of
uint64_t.
or something. Again, my C++ knowledge mostly died after C++98, so not sure
what the "right" answer is here.

I was being a bit lazy because the signature is hash_code hash_integer_value(uint64_t value), but you're right using underlying_type is probably better if hash_integer_value's input type were to change.

Fixed that.

Apr 9 2016, 1:31 PM
jfb committed rL265880: Fix hash_integer_value.
Fix hash_integer_value
Apr 9 2016, 1:30 PM
jfb committed rL265879: is_integral_or_enum ❥ enum class ⇒ hashable enum class.
is_integral_or_enum ❥ enum class ⇒ hashable enum class
Apr 9 2016, 1:10 PM
jfb closed D18938: is_integral_or_enum ❥ enum class ⇒ hashable enum class by committing rL265879: is_integral_or_enum ❥ enum class ⇒ hashable enum class.
Apr 9 2016, 1:10 PM
jfb added a comment to D18938: is_integral_or_enum ❥ enum class ⇒ hashable enum class.

This looks better than the hackery i came up with, so LGTM :)

One nit in case we want to care:

+ return ::llvm::hashing::detail::hash_integer_value((uint64_t)value);

So, you are guaranteed this value is either an enum, *or* convertible to
unsigned long long.

But what is the enum is not an unsigned type?

IE will this not still trigger on:

enum class e2: int {};

?

I know these are all just hash values, so who cares, but in practice, you
may just want to use an explicit cast to std::underlying_type instead of
uint64_t.
or something. Again, my C++ knowledge mostly died after C++98, so not sure
what the "right" answer is here.

Apr 9 2016, 1:08 PM
jfb updated the diff for D18938: is_integral_or_enum ❥ enum class ⇒ hashable enum class.
  • Use underlying_type
Apr 9 2016, 1:08 PM
jfb added a comment to D18775: NFC: make AtomicOrdering an enum class.

BTW, this is what i came up with, not sure if anyone has a better way

inline hash_code hash_value(const AtomicOrdering &AO) {

return static_cast<typename

std::underlying_type<AtomicOrdering>::type>(AO);
}

Apr 9 2016, 12:50 PM
jfb retitled D18938: is_integral_or_enum ❥ enum class ⇒ hashable enum class from to is_integral_or_enum ❥ enum class ⇒ hashable enum class.
Apr 9 2016, 12:48 PM

Apr 8 2016

jfb added inline comments to D18226: Codegen: Tail-duplicate during placement..
Apr 8 2016, 2:29 PM

Apr 7 2016

jfb added inline comments to D18200: Add __atomic_* lowering to AtomicExpandPass..
Apr 7 2016, 3:49 PM
jfb retitled D18876: NFC: unify clang / LLVM atomic ordering from to NFC: unify clang / LLVM atomic ordering.
Apr 7 2016, 3:47 PM
jfb retitled D18875: NFC: unify clang / LLVM atomic ordering from to NFC: unify clang / LLVM atomic ordering.
Apr 7 2016, 3:45 PM