Petar Avramovic [Thu, 14 Feb 2019 11:39:53 +0000 (11:39 +0000)]
[MIPS GlobalISel] Select branch instructions
Select G_BR and G_BRCOND for MIPS32.
Unconditional branch G_BR does not have register operand,
for that reason we only add tests.
Since conditional branch G_BRCOND compares register to zero on MIPS32,
explicit extension must be performed on i1 condition in order to set
high bits to appropriate value.
Max Kazantsev [Thu, 14 Feb 2019 11:10:29 +0000 (11:10 +0000)]
Make widenable condition transparent for MemoryWriteTracking
Side effects of widenable condition intrinsic are modelled via
InaccessibleMemOnly, and there is no way to say that it isn't
really writing any memory. This patch teaches MemoryWriteTracking
ignore this intrinsic.
Jeremy Morse [Thu, 14 Feb 2019 11:09:24 +0000 (11:09 +0000)]
Fix an accidentally flipped pair of arguments, NFCI
While rebasing a refactor in r353950 I accidentally swapped two function
arguments; one is SelectionDAGBuilders "current" DebugLoc, the other is the one
from the "current" debug intrinsic. They're probably always identical, but I
haven't proved that yet.
David Green [Thu, 14 Feb 2019 11:09:24 +0000 (11:09 +0000)]
[ARM] Ensure we update the correct flags in the peephole optimiser
The Arm peephole optimiser code keeps track of both an MI and a SubAdd that can
be used to optimise away a CMP. In the rare case that both are found and not
ruled-out as valid, we could end up setting the flags on the wrong one.
Instead make sure we are using SubAdd if it exists, as it will be closer to the
CMP.
The testcase here is a little theoretical, with a dead def of cpsr. It should
hopefully show the point.
Andrew Ng [Thu, 14 Feb 2019 11:08:49 +0000 (11:08 +0000)]
[Support] Fix TempFile::discard to not leave behind temporary files
Moved the remove of the temporary file to after the close to avoid
remove failures caused by ETXTBSY errors.
This issue was seen when FileOutputBuffer falls back to an in memory
buffer due to the inability to mmap the on disk file. This occurred when
running LLD on an Ubuntu VM in VirtualBox on a Windows host attempting
to write the output to a VirtualBox shared folder.
Daniel Sanders [Thu, 14 Feb 2019 00:15:28 +0000 (00:15 +0000)]
[globalisel][combine] Split existing rules into a match and apply step
Summary:
The declarative tablegen definitions split rules into match and apply steps.
Prepare for that by doing the same in the C++ implementations. This aids
some of the migration effort while the tablegen version is incomplete.
Jordan Rupprecht [Wed, 13 Feb 2019 23:39:41 +0000 (23:39 +0000)]
[llvm-ar][libObject] Fix relative paths when nesting thin archives.
Summary:
When adding one thin archive to another, we currently chop off the relative path to the flattened members. For instance, when adding `foo/child.a` (which contains `x.txt`) to `parent.a`, when flattening it we should add it as `foo/x.txt` (which exists) instead of `x.txt` (which does not exist).
As a note, this also undoes the `IsNew` parameter of handling relative paths in r288280. The unit test there still passes.
This was reported as part of testing the kernel build with llvm-ar: https://patchwork.kernel.org/patch/10767545/ (see the second point).
Stefan Pintilie [Wed, 13 Feb 2019 23:37:23 +0000 (23:37 +0000)]
[PowerPC][NFC] Added tests for prologue and epilogue code gen.
Added four test files to check the existing behaviour of prologue
and epilogue code generation. This patch was done as a setup for
the upcoming patch listed on Phabricator that will change how the
prologue and epilogue work.
The upcoming patch is: https://reviews.llvm.org/D42590
Philip Reames [Wed, 13 Feb 2019 23:01:11 +0000 (23:01 +0000)]
[SelectionDAG] Inline a single use helper function, and remove last non-MMO interface [NFC]
For D57601, we need to know whether the instruction is volatile. We'd either have to pass yet another parameter, or just standardize on the MMO interface. I chose the second.
Mark Lacey [Wed, 13 Feb 2019 22:56:43 +0000 (22:56 +0000)]
[RegAllocGreedy] Take last chance recoloring into account in evicting.
Last chance recoloring inserts into FixedRegisters those virtual
registers it is attempting to assign a physical register to.
We must consider these when we consider candidates for eviction so that
we do not end up evicting something while we are attempting to recolor
to assign it.
This is hitting in an out-of-tree target and no longer reproduces on
trunk. That does not appear to be a result of it having been fixed, but
rather, it appears that optimization changes and/or other changes to
register allocation mask the problem.
I haven't found a way to come up with a reasonable test case for this
(i.e. one that I can actually commit to open source, is reasonable
in size, and actually reproduces the issue).
Leonard Chan [Wed, 13 Feb 2019 22:22:48 +0000 (22:22 +0000)]
[NewPM] Second attempt at porting ASan
This is the second attempt to port ASan to new PM after D52739. This takes the
initialization requried by ASan from the Module by moving it into a separate
class with it's own analysis that the new PM ASan can use.
Changes:
- Split AddressSanitizer into 2 passes: 1 for the instrumentation on the
function, and 1 for the pass itself which creates an instance of the first
during it's run. The same is done for AddressSanitizerModule.
- Add new PM AddressSanitizer and AddressSanitizerModule.
- Add legacy and new PM analyses for reading data needed to initialize ASan with.
- Removed DominatorTree dependency from ASan since it was unused.
- Move GlobalsMetadata and ShadowMapping out of anonymous namespace since the
new PM analysis holds these 2 classes and will need to expose them.
Serge Guelton [Wed, 13 Feb 2019 22:11:09 +0000 (22:11 +0000)]
Revert r353962
Specialization of Optional for trivially copyable types yields failure on the buildbots I fail to reproduce locally.
Better safe than sorry, reverting.
Philip Reames [Wed, 13 Feb 2019 20:42:59 +0000 (20:42 +0000)]
[SelectionDAG] Kill last uses of getAtomic w/o a MMO operand [NFC]
The helper function was used by only two callers, and largely ended up providing distinct functionality based on optional arguments and opcode. Inline and simply to make the functionality much more clear.
Vedant Kumar [Wed, 13 Feb 2019 19:53:38 +0000 (19:53 +0000)]
[CodeExtractor] Only lift lifetime markers present in the extraction region
When CodeExtractor finds liftime markers referencing inputs to the
extraction region, it lifts these markers out of the region and inserts
them around the call to the extracted function (see r350420, PR39671).
However, it should *only* lift lifetime markers that are actually
present in the extraction region. I.e., if a start marker is present in
the extraction region but a corresponding end marker isn't (or vice
versa), only the start marker (or end marker, resp.) should be lifted.
Philip Reames [Wed, 13 Feb 2019 19:49:17 +0000 (19:49 +0000)]
[Tests] More unordered atomic lowering tests
This time, focused around narrowing and widening transformations. Also, include a few simple memory optimization tests to highlight missed oppurtunities. This is part of building up the test base for D57601.
Craig Topper [Wed, 13 Feb 2019 18:21:36 +0000 (18:21 +0000)]
[X86] Add 'fxsr' to the getHostCPUFeatures detection code.
We implicitly mark this feature as enabled when the target is 64-bits, but our detection code for -march=native didn't support it so you can't detect it on 32-bit targets.
Serge Guelton [Wed, 13 Feb 2019 18:12:04 +0000 (18:12 +0000)]
Re-commit rL353927, patch included
Make llvm::Optional<T> trivially copyable when T is trivially copyable
This is an ever-recurring issue (see https://bugs.llvm.org/show_bug.cgi?id=39427 and https://bugs.llvm.org/show_bug.cgi?id=35978)
but I believe that thanks to https://reviews.llvm.org/D54472 we can now ship a decent implementation of this.
Basically the fact that llvm::is_trivially_copyable has a consistent behavior across compilers should prevent any ABI issue,
and using in-place new instead of memcpy should keep compiler bugs away.
This patch is slightly different from the original revision https://reviews.llvm.org/rL353927 but achieves the same goal. It just avoids
going through std::conditional which may the code more explicit.
Petr Hosek [Wed, 13 Feb 2019 17:28:47 +0000 (17:28 +0000)]
[AArch64] Support reserving arbitrary general purpose registers
This is a follow up to D48580 and D48581 which allows reserving
arbitrary general purpose registers with the exception of registers
with special purpose (X8, X16-X18, X29, X30) and registers used by LLVM
(X0, X19). This change also generalizes some of the existing logic to
rely entirely on values generated from tablegen.
Jeremy Morse [Wed, 13 Feb 2019 16:33:05 +0000 (16:33 +0000)]
[DebugInfo][DAG] Either salvage dangling debug info or emit Undef DBG_VALUEs
In this patch SelectionDAG tries to salvage any dbg.values that are going to be
dropped, in case they can be recovered from Values in the current BB. It also
strengthens SelectionDAGs handling of dangling debug data, so that dbg.values
are *always* emitted (as Undef or otherwise) instead of dangling forever.
The motivation behind this patch exists in the new test case: a memory address
(here a bitcast and GEP) exist in one basic block, and a dbg.value referring to
the address is left in the 'next' block. The base pointer is live across all
basic blocks. In current llvm trunk the dbg.value cannot be encoded, and it
isn't even emitted as an Undef DBG_VALUE.
The change is simply: if we're definitely going to drop a dbg.value, repeatedly
apply salvageDebugInfo to its operand until either we find something that can
be encoded, or we can't salvage any further in which case we produce an Undef
DBG_VALUE. To know when we're "definitely going to drop a dbg.value",
SelectionDAG signals SelectionDAGBuilder when all IR instructions have been
encoded to force salvaging. This ensures that any dbg.value that's dangling
after DAG creation will have a corresponding DBG_VALUE encoded.
Jeremy Morse [Wed, 13 Feb 2019 15:53:10 +0000 (15:53 +0000)]
[DebugInfo][DAG] Refactor dbg.value lowering into its own method
This is a pure copy-and-paste job, moving the logic for lowering dbg.value
intrinsics to SDDbgValues into its own function. This is ahead of adding some
more users of this logic.
Jeremy Morse [Wed, 13 Feb 2019 13:37:33 +0000 (13:37 +0000)]
[DebugInfo][DAG] Limit special-casing of dbg.values for Arguments
SelectionDAGBuilder has special handling for dbg.value intrinsics that are
understood to define the location of function parameters on entry to the
function. To enable this, we avoid recording a dbg.value as a virtual register
reference if it might be such a parameter, so that it later hits
EmitFuncArgumentDbgValue.
This patch reduces the set of circumstances where we avoid recording a
dbg.value as a virtual register reference, to allow more "normal" variables
to be recorded that way. We now only bypass for potential parameters if:
* The dbg.value operand is an Argument,
* The Variable is a parameter, and
* The Variable is not inlined.
meaning it's very likely that the dbg.value is a function-entry parameter
location.
Andrea Di Biagio [Wed, 13 Feb 2019 11:02:42 +0000 (11:02 +0000)]
[MCA][Scheduler] Use latency information to further classify busy instructions.
This patch introduces a new instruction stage named 'IS_PENDING'.
An instruction transitions from the IS_DISPATCHED to the IS_PENDING stage if
input registers are not available, but their latency is known.
This patch also adds a new set of instructions named 'PendingSet' to class
Scheduler. The idea is that the PendingSet will only contain instructions that
have reached the IS_PENDING stage.
By construction, an instruction in the PendingSet is only dependent on
instructions that have already reached the execution stage. The plan is to use
this knowledge to identify bottlenecks caused by data dependencies (see
PR37494).
Jeremy Morse [Wed, 13 Feb 2019 10:54:53 +0000 (10:54 +0000)]
[DebugInfo][InstCombine] Prefer to salvage debuginfo over sinking it
When instcombine sinks an instruction between two basic blocks, it sinks any
dbg.value users in the source block with it, to prevent debug use-before-free.
However we can do better by attempting to salvage the debug users, which would
avoid moving where the variable location changes. If we successfully salvage,
still sink a (cloned) dbg.value with the sunk instruction, as the sunk
instruction is more likely to be "live" later in the compilation process.
If we can't salvage dbg.value users of a sunk instruction, mark the dbg.values
in the original block as being undef. This terminates any earlier variable
location range, and represents the fact that we've optimized out the variable
location for a portion of the program.
David Stenberg [Wed, 13 Feb 2019 09:34:07 +0000 (09:34 +0000)]
[DebugInfo] Stop changing labels for register-described parameter DBG_VALUEs
Summary:
This is a follow-up to D57510. This patch stops DebugHandlerBase from
changing the starting label for the first non-overlapping,
register-described parameter DBG_VALUEs to the beginning of the
function. That code did not consider what defined the registers, which
could result in the ranges for the debug values starting before their
defining instructions. We currently do not emit debug values for
constant values directly at the start of the function, so this code is
still useful for such values, but my intention is to remove the code
from DebugHandlerBase completely when we get there. One reason for
removing it is that the code violates the history map's ranges, which I
think can make it quite confusing when troubleshooting.
In D57510, PrologEpilogInserter was amended so that parameter DBG_VALUEs
now are kept at the start of the entry block, even after emission of
prologue code. That was done to reduce the degradation of debug
completeness from this patch. PR40638 is another example, where the
lexical-scope trimming that LDV does, in combination with scheduling,
results in instructions after the prologue being left without locations.
There might be other cases where the DBG_VALUEs are pushed further down,
for which the DebugHandlerBase code may be helpful, but as it now quite
often result in incorrect locations, even after the prologue, it seems
better to remove that code, and try to work our way up with accurate
locations.
In the long run we should maybe not aim to provide accurate locations
inside the prologue. Some single location descriptions, at least those
referring to stack values, generate inaccurate values inside the
epilogue, so we maybe should not aim to achieve accuracy for location
lists. However, it seems that we now emit line number programs that can
result in GDB and LLDB stopping inside the prologue when doing line
number stepping into functions. See PR40188 for more information.
A summary of some of the changed test cases is available in PR40188#c2.
Serge Guelton [Wed, 13 Feb 2019 09:31:22 +0000 (09:31 +0000)]
Make llvm::Optional<T> trivially copyable when T is trivially copyable
This is an ever-recurring issue (see https://bugs.llvm.org/show_bug.cgi?id=39427 and https://bugs.llvm.org/show_bug.cgi?id=35978)
but I believe that thanks to https://reviews.llvm.org/D54472 we can now ship a decent implementation of this.
Basically the fact that llvm::is_trivially_copyable has a consistent behavior across compilers should prevent any ABI issue,
and using in-place new instead of memcpy should keep compiler bugs away.
Michal Gorny [Wed, 13 Feb 2019 08:34:40 +0000 (08:34 +0000)]
[llvm] [cmake] Provide split include paths in LLVMConfig
Modify LLVMConfig to provide split variables for in-source and generated
include paths. Currently, it uses a single value for both
LLVM_INCLUDE_DIRS and LLVM_INCLUDE_DIR which works for install tree but
fails hard at build tree (where LLVM_INCLUDE_DIR incorrectly contains
multiple values).
Instead, put the generated directory in LLVM_INCLUDE_DIR, and the source
tree in LLVM_MAIN_INCLUDE_DIR which is consistent with in-LLVM builds.
For install tree, both variables will have the same value.
Anton Afanasyev [Wed, 13 Feb 2019 08:26:43 +0000 (08:26 +0000)]
[X86][SLP] Enable SLP vectorization for 128-bit horizontal X86 instructions (add, sub)
Try to use 64-bit SLP vectorization. In addition to horizontal instrs
this change triggers optimizations for partial vector operations (for instance,
using low halfs of 128-bit registers xmm0 and xmm1 to multiply <2 x float> by
<2 x float>).
Craig Topper [Wed, 13 Feb 2019 07:42:34 +0000 (07:42 +0000)]
[X86] Use default expansion for (i64 fp_to_uint f80) when avx512 is enabled on 64-bit targets to match what happens without avx512.
In 64-bit mode prior to avx512 we use Expand, but with avx512 we need to make f32/f64 conversions Legal so we use Custom and then do our own expansion for f80. But this seems to produce codegen differences relative to avx2. This patch corrects this.
Craig Topper [Wed, 13 Feb 2019 07:42:31 +0000 (07:42 +0000)]
[X86] Refactor the FP_TO_INTHelper interface. NFCI
-Pull the final stack load creation from the two callers into the helper.
-Return a single SDValue instead of a std::pair.
-Remove the Replace flag which isn't really needed.
Max Kazantsev [Wed, 13 Feb 2019 06:12:48 +0000 (06:12 +0000)]
[LoopSimplifyCFG] Re-enable const branch folding by default
Known underlying bugs have been fixed, intensive fuzz testing did not
find any new problems. Re-enabling by default. Feel free to revert if
it causes any functional failures.
The DWARF standard says that an empty compile unit is not valid:
> Each such contribution consists of a compilation unit header (see
> Section 7.5.1.1 on page 200) followed by a single DW_TAG_compile_unit or
> DW_TAG_partial_unit debugging information entry, together with its
> children.
Matt Arsenault [Tue, 12 Feb 2019 23:44:13 +0000 (23:44 +0000)]
AMDGPU: Try to use function specific ST
Subtargets are a function level property, so ideally we would
eliminate everywhere that needs to check the global one. Rename the
function to try avoiding confusion.
Matt Arsenault [Tue, 12 Feb 2019 23:30:11 +0000 (23:30 +0000)]
AMDGPU: Ignore CodeObjectV3 when inlining
This was inhibiting inlining of library functions when clang was
invoking the inliner directly. This is covering a bit of a mess with
subtarget feature handling, and this shouldn't be a subtarget
feature. The behavior is different depending on whether you are using
a -mattr flag in clang, or llc, opt.
Alina Sbirlea [Tue, 12 Feb 2019 23:05:40 +0000 (23:05 +0000)]
[LICM] Cap the clobbering calls in LICM.
Summary:
Unlimitted number of calls to getClobberingAccess can lead to high
compile times in pathological cases.
Switching EnableLicmCap flag from bool to int, and enabling to default 100.
(tested to be appropriate for current bechmarks)
We can revisit this value when enabling MemorySSA.
David Major [Tue, 12 Feb 2019 22:24:45 +0000 (22:24 +0000)]
[gn build] Separate debug and optimization settings
This patch adds an `is_optimized` variable, orthogonal to `is_debug`, to allow for a gn analogue to `RelWithDebInfo` builds.
As part of this we'll want to explicitly enable GC+ICF, for the sake of `is_debug && is_optimized` builds. The flags normally default to true except that if you pass `/DEBUG` they default to false.
Erik Pilkington [Tue, 12 Feb 2019 21:55:38 +0000 (21:55 +0000)]
Fix auto-upgrade for the new parameter to llvm.objectsize
r352664 added a 'dynamic' parameter to objectsize, but the AutoUpgrade
changes were incomplete. Also, fix an off-by-one error I made in the
upgrade logic that is now no longer unreachable.
Sean Fertile [Tue, 12 Feb 2019 20:03:04 +0000 (20:03 +0000)]
Fix undefined behaviour in PPCInstPrinter::printBranchOperand.
Fix the undefined behaviour introduced by my previous patch r353865 (left
shifting a potentially negative value), which was caught by the bots that run
UBSan.
Philip Reames [Tue, 12 Feb 2019 18:33:01 +0000 (18:33 +0000)]
[InlineSpiller] Fix a crash due to lack of forward progress from remat (try 2)
This is a recommit of r335091 Add more test cases for deopt-operands via regalloc, and r335077 [InlineSpiller] Fix a crash due to lack of forward progress from remat specifically for STATEPOINT. They were reverted due to a crash.
This change includes the text of both original changes, but also includes three aditional pieces:
1) A bug fix for the observed crash. I had failed to record the failed remat value as live which resulted in an instruction being deleted which still had uses. With the machine verifier, this is caught quickly. Without it, we fail in StackSlotColoring due to an empty live interval from LiveStack.
2) A test case which demonstrates the fix for (1). See @test11.
3) A control flag which defaults to disabling this for the moment. Once I've run more extensive validaton, I will switch the default and then remove this flag.
Daniel Sanders [Tue, 12 Feb 2019 17:36:57 +0000 (17:36 +0000)]
[tablegen] Add locations to many PrintFatalError() calls
Summary:
While working on the GISel Combiner, I noticed I was producing location-less
error messages fairly often and set about fixing this. In the process, I
noticed quite a few places elsewhere in TableGen that also neglected to include
a relevant location.
This patch adds locations to errors that relate to a specific record (or a
field within it) and also have easy access to the relevant location. This is
particularly useful when multiclasses are involved as many of these errors
refer to the full name of a record and it's difficult to guess which substring
is grep-able.
Unfortunately, tablegen currently only supports Record granularity so it's not
currently possible to point at a specific Init so these sometimes point at the
record that caused the error rather than the precise origin of the error.
Simon Pilgrim [Tue, 12 Feb 2019 17:22:35 +0000 (17:22 +0000)]
[X86][AVX] Enable shuffle combining support for zero_extend
A more limited version of rL352997 that had to be disabled in rL353198 - allow extension of any 128/256/512 bit vector that at least uses byte sized scalars.
Sanjay Patel [Tue, 12 Feb 2019 17:07:47 +0000 (17:07 +0000)]
[DAGCombiner] convert logic-of-setcc into bit magic (PR40611)
If we're comparing some value for equality against 2 constants
and those constants have an absolute difference of just 1 bit,
then we can offset and mask off that 1 bit and reduce to a single
compare against zero:
and/or (setcc X, C0, ne), (setcc X, C1, ne/eq) -->
setcc ((add X, -C1), ~(C0 - C1)), 0, ne/eq
https://rise4fun.com/Alive/XslKj
This transform is disabled by default using a TLI hook
("convertSetCCLogicToBitwiseLogic()").
That should be overridden for AArch64, MIPS, Sparc and possibly
others based on the asm shown in:
https://bugs.llvm.org/show_bug.cgi?id=40611
whitequark [Tue, 12 Feb 2019 16:41:50 +0000 (16:41 +0000)]
[SelectionDAG] Fix return calling convention in expansion of ?MULO
Summary:
The SMULO/UMULO DAG nodes, when not directly supported by the target,
expand to a multiplication twice as wide. In case that the resulting
type is not legal, the legalizer cannot directly call the intrinsic
with the wide arguments; instead, it "pre-lowers" them by splitting
them in halves.
rL283203 made sure that on big endian targets, the legalizer passes
the argument halves in the correct order. It did not do the same
for the return value halves because the existing code used a hack;
it put an illegal type into DAG and hoped that nothing would break
and it would be correctly lowered elsewhere.
rL307207 fixed this, handling return value halves similar to how
argument handles are handled, but did not take big-endian targets
into account.
This commit fixes the expansion on big-endian targets, such as
the out-of-tree OR1K target.
Jordan Rupprecht [Tue, 12 Feb 2019 15:01:07 +0000 (15:01 +0000)]
[llvm-dwp] Abort when dwo_id is unset
Summary:
An empty dwo_id indicates a degenerate .dwo file that should not have been generated in the first place. Instead of discovering this error later when merging with another degenerate .dwo file, print an error immediately when noticing an unset dwo_id, including the filename of the offending file.
Test case created by compiling a trivial file w/ `-fno-split-dwarf-inlining -gmlt -gsplit-dwarf -c` prior to r353771
Salvaging a redundant load instruction into a debug expression hides a
memory read from optimisation passes. Passes that alter memory behaviour
(such as LICM promoting memory to a register) aren't aware of these debug
memory reads and leave them unaltered, making the debug variable location
point somewhere unsafe.
Teaching passes to know about these debug memory reads would be challenging
and probably incomplete. Finding dbg.value instructions that need to be fixed
would likely be computationally expensive too, as more analysis would be
required. It's better to not generate debug-memory-reads instead, alas.
Changed tests:
* DeadStoreElim: test for salvaging of intermediate operations contributing
to the dead store, instead of salvaging of the redundant load,
* GVN: remove debuginfo behaviour checks completely, this behaviour is still
covered by other tests,
* InstCombine: don't test for salvaged loads, we're removing that behaviour.
David Stenberg [Tue, 12 Feb 2019 10:51:27 +0000 (10:51 +0000)]
[DebugInfo] Keep parameter DBG_VALUEs before prologue code
Summary:
This is a preparatory change for removing the code from
DebugHandlerBase::beginFunction() which changes the starting label for
the first non-overlapping DBG_VALUEs of parameters to the beginning of
the function. It does that to be able to show parameters when entering a
function. However, that code does not consider what defines the values,
which can result in the ranges for the debug values starting before
their defining instructions. That code is removed in a follow-up patch.
When prologue code is inserted, it leads to DBG_VALUEs that start
directly in the entry block being moved down after the prologue
instructions. This patch fixes that by stashing away DBG_VALUEs for
parameters before emitting the prologue, and then reinserts them at the
start of the block. This assumes that there is no target that somehow
clobbers parameter registers in the frame setup; there is no such case
in the lit tests at least.
projects / llvm / log