Page MenuHomePhabricator

jfb (JF Bastien)
User

Projects

User does not belong to any projects.

User Details

User Since
Jan 27 2014, 9:36 AM (254 w, 2 d)

Recent Activity

Yesterday

jfb added a comment to D55562: Atomics: support min/max orthogonally.

What does it do with floating-point inputs?

Tue, Dec 11, 10:53 AM

Mon, Dec 10

jfb created D55531: AsmParser: test .double NaN.
Mon, Dec 10, 3:52 PM
jfb updated the summary of D54604: Automatic variable initialization.
Mon, Dec 10, 3:01 PM
jfb updated the diff for D54604: Automatic variable initialization.
  • Make sure uninit-variables.c doesn't break.
  • Address Peter's comments, improve tests.
  • Add an ugly option to enable zero init
  • Update warning-flags.c
  • Fix typo
  • Use negative NaN with repeated 0xFF payload for all floating-point types. This is potentially faster to initialize than pure positive no-payload NaNs.
Mon, Dec 10, 2:55 PM
jfb added a comment to D55517: Remove `_VSTD`.
In D55517#1325917, @jfb wrote:

I think your commit message is fun and terse, but it doesn't say why you're actually correct. You're explaining it here, Marshall has voiced concerns about downsides. I think your commit message should explain this and say why you think the downsides aren't relevant. That makes it easier to go back to your change in the future and understand why the change was OK without looking at this discussion.

How's the new commit message?

Mon, Dec 10, 12:16 PM
jfb committed rL348791: APFloat: allow 64-bit of payload.
APFloat: allow 64-bit of payload
Mon, Dec 10, 11:30 AM
jfb closed D55460: APFloat: allow 64-bit of payload.
Mon, Dec 10, 11:30 AM
jfb added a comment to D55517: Remove `_VSTD`.
In D55517#1325835, @jfb wrote:
In D55517#1325586, @jfb wrote:

Quick Question: What's the difference between writing _VSTD:: and std::? Nothing.

I thought it was std:: _LIBCPP_ABI_NAMESPACE ?

That's correct, however I don't think it's a big deal. Indeed, discussed it and we couldn't find a reason why we would ever want to call a function that is not in the current ABI's namespace. And even if we did, we could always use std::<ABI namespace>::function.

Sure, my point is that the commit message isn't right, and should be updated to have this rationale.

I think the commit message is correct. There is no functional difference, and the fact that _VSTD spells of std::__1 is functionally a distinction without a difference.
I purposefully omitted any mention of mixing ABI versions internally because the idea is non-functional. We only ever have one versioning namespace, what other version are we expecting to want to call?

Mon, Dec 10, 11:28 AM
jfb updated the diff for D55460: APFloat: allow 64-bit of payload.
  • Also add ConstantFP NaN getters which match the APFloat ones (with getQNaN / getSNaN and APInt parameters).
Mon, Dec 10, 10:52 AM
jfb added a comment to D55517: Remove `_VSTD`.
In D55517#1325586, @jfb wrote:

Quick Question: What's the difference between writing _VSTD:: and std::? Nothing.

I thought it was std:: _LIBCPP_ABI_NAMESPACE ?

That's correct, however I don't think it's a big deal. Indeed, discussed it and we couldn't find a reason why we would ever want to call a function that is not in the current ABI's namespace. And even if we did, we could always use std::<ABI namespace>::function.

Mon, Dec 10, 10:48 AM
jfb added a comment to D55460: APFloat: allow 64-bit of payload.

Oh, actually, please embellish the unit test to include some >32-bit payloads when building double-typed NaNs.

Mon, Dec 10, 10:36 AM
jfb updated the diff for D55460: APFloat: allow 64-bit of payload.
  • Add tests
Mon, Dec 10, 10:36 AM
jfb added a comment to D55517: Remove `_VSTD`.

Quick Question: What's the difference between writing _VSTD:: and std::? Nothing.

Mon, Dec 10, 9:24 AM

Fri, Dec 7

jfb added a comment to D55460: APFloat: allow 64-bit of payload.

This truncates the payload to fit into the significand field. Presumably that includes setting the top bit of the significand to make this a NaN and not an infinity. Does it also always form a qNaN, or can you create an sNaN this way?

Fri, Dec 7, 4:01 PM
jfb added a comment to D55460: APFloat: allow 64-bit of payload.

Testing-wise, this isn't tested in APFloatTest.cpp, so I'm keeping the status-quo.
The only place where it's used in an odd way is for the floating-literals.s test (which tries to match the GNU as behavior). The test makes me uneasy because it's using ~0 to create a .single NaN... and I have no idea what's the right behavior for .double... This is better fixed in a follow-up.

Fri, Dec 7, 3:56 PM
jfb created D55460: APFloat: allow 64-bit of payload.
Fri, Dec 7, 3:54 PM
jfb updated the diff for D54604: Automatic variable initialization.
  • Fix typo
Fri, Dec 7, 3:42 PM
jfb updated the diff for D54604: Automatic variable initialization.
  • Update warning-flags.c
Fri, Dec 7, 2:53 PM
jfb added a comment to D54604: Automatic variable initialization.

I added an option that's required when using clang directly (*not* -cc1!) If you use -ftrivial-auto-var-init=zero without -enable-trivial-auto-var-init-zero-knowning-it-will-be-removed-from-clang in clang it'll generate a warning and change initialization to pattern initialization instead. That's roughly along the lines people were going for on cfe-dev.

Fri, Dec 7, 2:48 PM
jfb updated the diff for D54604: Automatic variable initialization.
  • Add an ugly option to enable zero init
Fri, Dec 7, 2:46 PM
jfb added a comment to D54604: Automatic variable initialization.

I've addressed @pcc's comments. I'll now update the patch to mandate a -Xclang option for zero-init (otherwise it'll warn and pattern-init instead), and remove documentation for zero-init. I'm also thinking of changing float init to negative NaN with infinite scream payload.

Fri, Dec 7, 11:35 AM
jfb updated the diff for D54604: Automatic variable initialization.
  • Make sure uninit-variables.c doesn't break.
  • Address Peter's comments, improve tests.
Fri, Dec 7, 11:33 AM

Thu, Dec 6

jfb added inline comments to D52416: Allow FP types for atomicrmw xchg.
Thu, Dec 6, 9:11 AM
jfb added inline comments to D52416: Allow FP types for atomicrmw xchg.
Thu, Dec 6, 9:03 AM

Tue, Dec 4

jfb added a comment to D53994: Fixing lower bound regression in certain situations..

I'm surprised the codegen is so much worst, even with __builtin_assume(l >= f); it's bad. We'll look at improving LLVM's codegen for this, in the meantime I guess this patch is fine.

Tue, Dec 4, 10:52 AM

Mon, Nov 26

jfb reopened D54543: [stack-safety] Inter-Procedural Analysis implementation.

Please fix the build break introduced.

Mon, Nov 26, 3:52 PM
jfb committed rL347616: Fix debug build break.
Fix debug build break
Mon, Nov 26, 3:51 PM
jfb added inline comments to D35035: [InstCombine] Prevent memcpy generation for small data size.
Mon, Nov 26, 10:49 AM

Fri, Nov 16

jfb added a comment to D54604: Automatic variable initialization.
In D54604#1301807, @kcc wrote:

Would it be possible to extend test/Sema/uninit-variables.c to verify that the new option
doesn't break -Wuninitialized?

Fri, Nov 16, 3:56 PM
jfb updated the diff for D54604: Automatic variable initialization.
  • Make sure uninit-variables.c doesn't break.
Fri, Nov 16, 3:54 PM
jfb updated subscribers of D54630: Move detection of libc++ include dirs to Driver on MacOS.
Fri, Nov 16, 10:40 AM

Thu, Nov 15

jfb updated the summary of D54604: Automatic variable initialization.
Thu, Nov 15, 4:43 PM
jfb added a comment to D54604: Automatic variable initialization.

This isn't meant to change the semantics of C and C++.

As I said in the cfe-dev thread, that's exactly what it does. Specifically I think this is essentially defining a new dialect of C++, which I have massive concerns about. Additionally, as much as we might claim it's a transitional measure, we all know that's not how it'll be used in practice.

Thu, Nov 15, 4:43 PM
jfb created D54604: Automatic variable initialization.
Thu, Nov 15, 2:52 PM

Wed, Nov 14

jfb committed rC346915: CGDecl::emitStoresForConstant fix synthesized constant's name.
CGDecl::emitStoresForConstant fix synthesized constant's name
Wed, Nov 14, 4:22 PM
jfb committed rL346915: CGDecl::emitStoresForConstant fix synthesized constant's name.
CGDecl::emitStoresForConstant fix synthesized constant's name
Wed, Nov 14, 4:22 PM
jfb closed D54055: CGDecl::emitStoresForConstant fix synthesized constant's name.
Wed, Nov 14, 4:21 PM
jfb added inline comments to D54055: CGDecl::emitStoresForConstant fix synthesized constant's name.
Wed, Nov 14, 1:15 PM
jfb updated the diff for D54055: CGDecl::emitStoresForConstant fix synthesized constant's name.
  • Inline the name creating, save a heap allocation.
Wed, Nov 14, 1:14 PM
jfb added a comment to D54055: CGDecl::emitStoresForConstant fix synthesized constant's name.

Small update to use std::string because Twine lifetimes are sad. This didn't trigger on any of the tests, but did in a stage2 build.

Wed, Nov 14, 12:53 PM
jfb updated the diff for D54055: CGDecl::emitStoresForConstant fix synthesized constant's name.
  • Fix lifetime of the name, Twine bites again.
Wed, Nov 14, 12:52 PM

Tue, Nov 13

jfb retitled D54055: CGDecl::emitStoresForConstant fix synthesized constant's name from CXXNameMangler::mangleFunctionParam: fix assertion to CGDecl::emitStoresForConstant fix synthesized constant's name.
Tue, Nov 13, 3:19 PM
jfb updated the diff for D54055: CGDecl::emitStoresForConstant fix synthesized constant's name.
  • clang-format
Tue, Nov 13, 3:15 PM
jfb added a comment to D54055: CGDecl::emitStoresForConstant fix synthesized constant's name.

Pfft, if I'm going to be held responsible for my own work, I'm in a lot of trouble. :)

Function name + local variable name WFM.

Tue, Nov 13, 3:14 PM
jfb updated the diff for D54055: CGDecl::emitStoresForConstant fix synthesized constant's name.
  • As discussed on the review, change the constant generation to name the synthesized constant using '__const.' + function_name + '.' variable_name. The previous code wasn't generally correct because it was trying to mangle the variable as if it were a static, and in some cases this could pull in e.g. parameter names (which is nonsensical for a static). This only occurs with a patch which I haven't submitted yet, but my change is pretty well tested already as the modified tests show.
Tue, Nov 13, 3:12 PM
jfb added a comment to D35035: [InstCombine] Prevent memcpy generation for small data size.
In D35035#1284164, @jfb wrote:

Not sure what is the general consensus wrt this patch, but i guess it now consistently uses bytes.

Agree - the code change looks like what I expected now.

So:

  1. Is @jfb objecting to this as an intermediate improvement?

My concern is here: https://reviews.llvm.org/D35035#inline-464768
This uses an unrelated constant to drive optimization decisions. Create a new per-target constant.

I think the intent of this patch is to do best-effort without relying a lot on target specific constants. Will it help to have per-target constant only for mem* functions? Could that constant be used to drive other optimizations?

Tue, Nov 13, 9:58 AM
jfb requested changes to D54456: [libcxx] Allow use of <atomic> in baremetal systems when threading is disabled..

I strongly feel like this should be part of a Freestanding effort with an overarching design. I haven't seen any of this yet.

So: I want this, but I want to know (and agree on) how we're going to do the rest, too.

Tue, Nov 13, 9:48 AM

Nov 9 2018

jfb added a comment to D54291: [XRay] Add atomic fences around non-atomic reads and writes.

What is the point of this change? The atomic_fetch_add operations already use memory_order_acq_rel, so the explicit fences are redundant.

Nov 9 2018, 8:41 PM

Nov 3 2018

jfb added a comment to D54055: CGDecl::emitStoresForConstant fix synthesized constant's name.
In D54055#1286397, @jfb wrote:

That sounds more like this use of the mangler isn't manipulating the function type context correctly. But actually I think the problem is that it's ridiculous to assume that arbitrary local declarations have meaningful manglings. Why are we calling getStaticDeclName on a variable that's obviously not static?

It was done in CodeGenFunction::EmitAutoVarInit a while ago. I moved it since then, but it's the same thing. I'm happy to mangle it any other way. At the end of the day we just need some name for an (unnamed address) global which is synthesized from a function-local initialization. We could just take the mangled function name and append something to it.

Okay. I assume this is internal-linkage and the name is just for debugging purposes? Maybe we could have an API to generate a best-effort name mangling that could intentionally punt on variably-modified types.

Nov 3 2018, 11:44 AM

Nov 2 2018

jfb added a comment to D54055: CGDecl::emitStoresForConstant fix synthesized constant's name.

That sounds more like this use of the mangler isn't manipulating the function type context correctly. But actually I think the problem is that it's ridiculous to assume that arbitrary local declarations have meaningful manglings. Why are we calling getStaticDeclName on a variable that's obviously not static?

Nov 2 2018, 10:33 PM
jfb added a comment to D54055: CGDecl::emitStoresForConstant fix synthesized constant's name.

Can you give an example of some code that triggered this with your patch applied? Even if it isn't a real reproducer right now, it would help to try to understand whats happening here.

Nov 2 2018, 4:22 PM
jfb added a comment to D54055: CGDecl::emitStoresForConstant fix synthesized constant's name.

I'm not sure this is the right fix because mangling confuses me. It fixes the assertion I'm encountering in my patch, and I don't think I can create a repro without the patch (since I'm asking to mangle a local in a way we don't seem to right now).

Nov 2 2018, 3:50 PM
jfb created D54055: CGDecl::emitStoresForConstant fix synthesized constant's name.
Nov 2 2018, 3:50 PM

Nov 1 2018

jfb added a comment to D53965: IR: Add fp operations to atomicrmw.

AFAIK we don't care about FP flags at all here, correct? Even strictfp is irrelevant.

We can't algebraically combine this, so the flags shouldn't matter.

Nov 1 2018, 11:13 AM
jfb added a comment to D35035: [InstCombine] Prevent memcpy generation for small data size.

Not sure what is the general consensus wrt this patch, but i guess it now consistently uses bytes.

Agree - the code change looks like what I expected now.

So:

  1. Is @jfb objecting to this as an intermediate improvement?
Nov 1 2018, 10:44 AM
jfb added a comment to D53965: IR: Add fp operations to atomicrmw.

Is this to support wg21.link/p0020 ?

Nov 1 2018, 10:35 AM

Oct 24 2018

jfb added a comment to D53424: Enable thread specific cl::opt values for multi-threaded support.

May I ask why you think it's important to move away from cl::opt in the first place? What purpose does it actually solve?

Oct 24 2018, 9:02 AM
jfb added a comment to D53486: [libcxx] Only define __libcpp_is_floating_point<_Float16> for Clang.

We're looking into this. Stay tuned.

Oct 24 2018, 8:54 AM

Oct 23 2018

jfb added a comment to D53424: Enable thread specific cl::opt values for multi-threaded support.

This is a very good summary. I would suggest that we land this patch and mark this feature as a temporary solution asking the users to consider moving the options they redefine to the new API D5389.

Oct 23 2018, 8:26 PM

Oct 22 2018

jfb added a comment to D53424: Enable thread specific cl::opt values for multi-threaded support.

Can you explain what you would use per-thread command line options for?
Intuitively I would not expect actual commandline users wanting to set options per thread. If you need it to tweak compiler behavior then it might be better to find ways to encode the information in TargetOptions.h, function attributes or similar, so we have a streamlined way of setting them independently of programmatically modifying commandline options.

It's about proper encapsulation of state.

There are use cases where there are multiple components using LLVM in the same process for different purposes, and we should really be able to properly isolate those purposes. The use case that I care about is Mesa, where one of the users is an OpenGL driver (using LLVM as a shader compiler backend) which may be loaded into an application that uses LLVM for something else as well.

Oct 22 2018, 10:09 AM

Oct 11 2018

jfb accepted D53181: SelectionDAG: Reuse bigger sized constants in memset expansion..

Nice! LGTM, assuming folks are OK with the llvm.org/pr38771 change.

Oct 11 2018, 4:39 PM
jfb added a comment to D53154: [CodeGen] Handle extern references to OBJC_CLASS_$_*.

Overall this seems fine, but I'm no ObjC expert either so I'll defer to @rjmccall

Oct 11 2018, 11:22 AM

Oct 9 2018

jfb added a comment to D52949: [Diagnostics] Implement -Wsizeof-pointer-div .

Can you add tests with arrays?
The error message doesn't really say what to do instead. What's wrong? What's correct instead?
In C++17 and later we should suggest using std::size for some cases instead.

Oct 9 2018, 9:05 PM
jfb added a comment to D32564: AArch64: compress jump tables to minimum size needed to reach destinations.
In D32564#1259155, @jfb wrote:

Do you have specific worries? Or at least a timeline? Seems the patch can be reviewed without waiting for your exploration.

Yes, I do. Exynos limits the size of jump tables, resulting in a daisy chain of smaller jump tables. This patch changes the jump table code, so I'd like to evaluate the performance impact, unless this pass is gated by -Os.

Oct 9 2018, 4:34 PM
jfb added a comment to D32564: AArch64: compress jump tables to minimum size needed to reach destinations.

This is good data. However, I'd like to evaluate this patch a bit further on Exynos, if I may.

Oct 9 2018, 11:22 AM

Oct 8 2018

jfb accepted D53001: [Driver] check for exit code from SIGPIPE.

Digging through tools/driver/driver.cpp this seems to be the right thing. Maybe leave it open for a bit so others can chime in (if say they have other drivers or whatever?). Thanks for fixing!

Oct 8 2018, 5:00 PM
jfb added a comment to D53001: [Driver] check for exit code from SIGPIPE.

Just to be sure: what's the exit code from the driver? If we don't diagnose I'm fine with it... but the exit code still needs to reflect the failure!

Oct 8 2018, 4:16 PM
jfb accepted D53000: [Support] exit with custom return code for SIGPIPE.
Oct 8 2018, 4:15 PM
jfb added inline comments to D53001: [Driver] check for exit code from SIGPIPE.
Oct 8 2018, 3:58 PM
jfb added inline comments to D53000: [Support] exit with custom return code for SIGPIPE.
Oct 8 2018, 3:41 PM
jfb added a comment to D53001: [Driver] check for exit code from SIGPIPE.

What's the return code of the driver when the pipe is broken that way?

Oct 8 2018, 3:41 PM
jfb added a comment to D53000: [Support] exit with custom return code for SIGPIPE.

Can you clarify the description: we tell the user to file a bug report on LLVM right now, and sigpipe ins't LLVM's fault so our error message is wrong.

Oct 8 2018, 2:48 PM

Oct 4 2018

jfb added a comment to D52896: MergeSimilarFunctions 1/n: a code size pass to merge functions with small differences.

I don't understand: why is it desirable to have this as a separate thing compared to merge funcs? It seems better to use the same code for both, and when calling mergefuncs pass in a mode which chooses to merge exact matches, or similar matches.

Oct 4 2018, 11:26 AM
jfb added a comment to D52892: [Clang-tidy] readability check to convert numerical constants to std::numeric_limits.

Can you also catch casts such as (unsigned)-1 ?

Oct 4 2018, 10:56 AM ยท Restricted Project

Oct 2 2018

jfb added a comment to D35035: [InstCombine] Prevent memcpy generation for small data size.

Perhaps the impact is negligible, non-existent, and we worry about this for nothing. As also suggested earlier, I will try to get some numbers on the table for ARM and AArch64 if we strip out the lowering here, if that is helpful for this discussion, but probably need a day or two to get them.

If you could provide some numbers, I can go ahead and remove the inlining of memcpy altogether provided the reviewers agree with it, or we can merge this patch which is trying to improve on previously hardcoded numbers.

Yes, I support removing the expansion entirely, but I don't think we can commit that change without doing some advance perf testing.
And yes, in the best case, we'll discover that there are no regressions because all of the other analyses and lowering will do the transform as intended when it's profitable.

Just to drop a nit, here is a somewhat idiomatic pattern, that is recommended to avoid breaking strict aliasing: https://godbolt.org/z/_JNwOp
If we don't do this memcpy expansion where, will we have memcpy till the backend?
Surely this is not good.

That case (and a couple of similar tests that I tried) are handled by -sroa, so they probably never made it to instcombine in the 1st place. I don't know anything about SROA, but hopefully, it's making that transform using some principled logic. :)

Oct 2 2018, 1:50 PM
jfb added a comment to D47073: Document and Enforce new Host Compiler Policy.

Related to this patch, don't forget to attend the BoF at the upcoming LLVM dev meeting: https://llvm.org/devmtg/2018-10/talk-abstracts.html#bof3 ๐ŸŽ‰

Oct 2 2018, 12:49 PM
jfb added inline comments to D35035: [InstCombine] Prevent memcpy generation for small data size.
Oct 2 2018, 9:55 AM
jfb added inline comments to D35035: [InstCombine] Prevent memcpy generation for small data size.
Oct 2 2018, 9:24 AM

Oct 1 2018

jfb updated subscribers of D35035: [InstCombine] Prevent memcpy generation for small data size.
Oct 1 2018, 10:46 AM
jfb added a comment to D35035: [InstCombine] Prevent memcpy generation for small data size.

I don't understand why it makes sense to tie this to the larger integer type. I understand that targets might want what you're doing, but tying it to the largest integer type instead of having a separate target-specific value seems odd.
How does this interact with memcpyopt?
Which targets are affected by this change?
Can you please provide size and performance numbers for relevant targets?

Oct 1 2018, 10:46 AM

Sep 24 2018

jfb added a comment to D52416: Allow FP types for atomicrmw xchg.

What does this look like with half, fp80, fp128?
Does this not change anything on other architectures?

Sep 24 2018, 9:36 AM
jfb accepted D52414: IR: Move AtomicRMW string names into class.
Sep 24 2018, 9:23 AM
jfb accepted D52415: Add atomicrmw operation to error messages.
Sep 24 2018, 9:23 AM

Sep 21 2018

jfb committed rL342759: [NFC] use bit_cast in PointerSumType.
[NFC] use bit_cast in PointerSumType
Sep 21 2018, 11:37 AM
jfb committed rC342750: [NFC] remove unused variable.
[NFC] remove unused variable
Sep 21 2018, 10:40 AM
jfb committed rL342750: [NFC] remove unused variable.
[NFC] remove unused variable
Sep 21 2018, 10:40 AM
jfb added a comment to D52339: Support enums with a fixed underlying type in all language modes.
In D52339#1242086, @jfb wrote:

I think we should consider proposing this to the C committee. @aaron.ballman I can help Erik write the paper, would you be able to present it? Too tight for the upcoming meeting, but I'm guessing we have *plenty* of time for ++C17.

It's already been proposed to WG14 and is currently on the SD-3 list of features to consider for C2x. See http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2008.pdf. I know Clive and am happy to point him towards this patch (when it lands) as demonstration of industry desire for the feature, in case he needs to provide updated papers.

Sep 21 2018, 9:46 AM
jfb added inline comments to D32564: AArch64: compress jump tables to minimum size needed to reach destinations.
Sep 21 2018, 9:40 AM
jfb added a comment to D52339: Support enums with a fixed underlying type in all language modes.

I think we should consider proposing this to the C committee. @aaron.ballman I can help Erik write the paper, would you be able to present it? Too tight for the upcoming meeting, but I'm guessing we have *plenty* of time for ++C17.

Sep 21 2018, 9:26 AM
jfb added inline comments to D52092: [ValueTracking] Generalize isBytewiseValue into isSplatValue.
Sep 21 2018, 9:00 AM
jfb added a comment to D52332: [ADT] restrict bit_cast to trivially-constructible To.

Re-landed as r342739.

Sep 21 2018, 7:33 AM
jfb committed rL342739: [ADT] restrict bit_cast to trivially-constructible To.
[ADT] restrict bit_cast to trivially-constructible To
Sep 21 2018, 7:32 AM
jfb committed rC342734: NFC: deduplicate isRepeatedBytePattern from clang to LLVM's isBytewiseValue.
NFC: deduplicate isRepeatedBytePattern from clang to LLVM's isBytewiseValue
Sep 21 2018, 6:55 AM
jfb committed rL342734: NFC: deduplicate isRepeatedBytePattern from clang to LLVM's isBytewiseValue.
NFC: deduplicate isRepeatedBytePattern from clang to LLVM's isBytewiseValue
Sep 21 2018, 6:55 AM
jfb closed D51752: NFC: deduplicate isRepeatedBytePattern from clang to LLVM's isBytewiseValue.
Sep 21 2018, 6:55 AM

Sep 20 2018

jfb added a comment to D52332: [ADT] restrict bit_cast to trivially-constructible To.

Had to revert, this was in GCC 5.1 only. I'll fix tomorrow.

Sep 20 2018, 10:41 PM
jfb committed rL342711: Revert "[ADT] restrict bit_cast to trivially-constructible To".
Revert "[ADT] restrict bit_cast to trivially-constructible To"
Sep 20 2018, 10:35 PM
jfb committed rL342710: [ADT] restrict bit_cast to trivially-constructible To.
[ADT] restrict bit_cast to trivially-constructible To
Sep 20 2018, 10:22 PM
jfb closed D52332: [ADT] restrict bit_cast to trivially-constructible To.
Sep 20 2018, 10:22 PM
jfb committed rL342709: Merge clang's isRepeatedBytePattern with LLVM's isBytewiseValue.
Merge clang's isRepeatedBytePattern with LLVM's isBytewiseValue
Sep 20 2018, 10:22 PM