| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
For targets that have instruction itineraries this means no change. Targets
that move over to the new schedule model will use be able the new schedule
module for instruction latencies in the if-converter (the logic is such that if
there is no itineary we will use the new sched model for the latencies).
Before, we queried "TTI->getInstructionLatency()" for the instruction latency
and the extra prediction cost. Now, we query the TargetSchedule abstraction for
the instruction latency and TargetInstrInfo for the extra predictation cost. The
TargetSchedule abstraction will internally call "TTI->getInstructionLatency" if
an itinerary exists, otherwise it will use the new schedule model.
ATTENTION: Out of tree targets!
(I will also send out an email later to LLVMDev)
This means, if your target implements
unsigned getInstrLatency(const InstrItineraryData *ItinData,
const MachineInstr *MI,
unsigned *PredCost);
and returns a value for "PredCost", you now also need to implement
unsigned getPredictationCost(const MachineInstr *MI);
(if your target uses the IfConversion.cpp pass)
radar://15077010
llvm-svn: 191671
|
| |
|
|
|
|
|
|
|
| |
Enable building the LTO library (.lib and.dll) and llvm-lto.exe on Windows with
MSVC and Mingw as well as re-enabling the associated test.
Patch by Greg Bedwell!
llvm-svn: 191670
|
| |
|
|
|
|
| |
clang-apply-replacements unittest Makefile wasn't linking in TransformUtils.
llvm-svn: 191669
|
| |
|
|
|
|
|
|
|
| |
when it was actually a Constant*.
There are quite a few other casts to Instruction that might have the same problem,
but this is the only one I have a test case for.
llvm-svn: 191668
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
The tool now supports a collection of arguments to turn on and provide settings
for the formatting of code affected by applying replacements:
* --format turns on formatting (default style is LLVM)
* --style controls code style settings
* --style-config allows one to explicitly indicate where a style config file
lives.
The libclangApplyReplacements interface has a new function to turn Replacements
into Ranges to be used with tooling::reformat().
llvm-svn: 191667
|
| |
|
|
|
|
|
|
|
| |
The help text for clang-format's -style option and the function that processes
its value is moved to libFormat in this patch. The goal is to enable other
tools that use libFormat and also have a -style option to behave consistently
with clang-format.
llvm-svn: 191666
|
| |
|
|
|
|
|
|
| |
TemplateDeclInstantiator takes the MultiLevelArgumentList by const-ref
and stores a const-ref member. Thus, we must not pass a temporary
into the constructor.
llvm-svn: 191665
|
| |
|
|
| |
llvm-svn: 191664
|
| |
|
|
|
|
|
|
| |
For some reason, adding definitions for these load and store
instructions changed whether some of the build bots matched
comparisons as signed or unsigned.
llvm-svn: 191663
|
| |
|
|
| |
llvm-svn: 191662
|
| |
|
|
| |
llvm-svn: 191661
|
| |
|
|
|
|
|
|
|
| |
The only thing this does on its own is make the definitions of RISB[HL]G
a bit more precise. Those instructions are only used by the MC layer at
the moment, so no behavioral change is intended. The class is needed by
later patches though.
llvm-svn: 191660
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Use subreg_hNN and subreg_lNN for the high and low NN bits of a register.
List the low registers first, so that subreg_l32 also means the low 32
bits of a 128-bit register.
Floats are stored in the upper 32 bits of a 64-bit register, so they
should use subreg_h32 rather than subreg_l32.
No behavioral change intended.
llvm-svn: 191659
|
| |
|
|
|
|
| |
It now points to the equivalent page on imgtec.com
llvm-svn: 191658
|
| |
|
|
|
|
|
|
|
|
| |
CMAKE_MODULE_PATH.
Otherwise if libcxx is built as an LLVM external project (after r191624),
"include(config-ix)" will include config-ix.cmake from LLVM, not from libcxx,
which will result in misconfigured build tree.
llvm-svn: 191657
|
| |
|
|
| |
llvm-svn: 191656
|
| |
|
|
|
|
|
|
| |
I'm about to add support for high-word operations, so it seemed better
for the low-word registers to have names like R0L rather than R0W.
No behavioral change intended.
llvm-svn: 191655
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously, comments, could totally confuse it.
Before:
return
// true if code is one of a or b.
code == a ||
code == b;
After:
return
// true if code is one of a or b.
code == a || code == b;
llvm-svn: 191654
|
| |
|
|
|
|
|
|
|
|
| |
such option I've been able to find in the wild in our build system.
Note that I haven't added test cases for this. I can do so if folks
want, but they're *really* boring considering that this is all generated
code to parse and ignore unsued options.
llvm-svn: 191653
|
| |
|
|
|
|
| |
about ~43K from a released build. Unfortunately the disassembler tables are still upwards of 800K.
llvm-svn: 191652
|
| |
|
|
|
|
|
| |
prefix. Sort the ignored boolean 'f' flags at the bottom of this file.
No functionality changed.
llvm-svn: 191651
|
| |
|
|
|
|
| |
regards to combinations of L and W-bits.
llvm-svn: 191650
|
| |
|
|
|
|
|
|
|
|
|
| |
Add VEX_LIG to scalar FMA4 instructions.
Use VEX_LIG in some of the inheriting checks in disassembler table generator.
Make use of VEX_L_W, VEX_L_W_XS, VEX_L_W_XD contexts.
Don't let VEX_L_W, VEX_L_W_XS, VEX_L_W_XD, VEX_L_W_OPSIZE inherit from their non-L forms unless VEX_LIG is set.
Let VEX_L_W, VEX_L_W_XS, VEX_L_W_XD, VEX_L_W_OPSIZE inherit from all of their non-L or non-W cases.
Increase ranking on VEX_L_W, VEX_L_W_XS, VEX_L_W_XD, VEX_L_W_OPSIZE so they get chosen over non-L/non-W forms.
llvm-svn: 191649
|
| |
|
|
| |
llvm-svn: 191648
|
| |
|
|
|
|
| |
I got a bunch of buildbot failures that i don't understand - sorry.
llvm-svn: 191647
|
| |
|
|
|
|
|
| |
As Richard pointed out to me, dyn_cast is very cheap - there is no real benefit from adding cluttery overloads to only avoid that cast.
No functionality change.
llvm-svn: 191646
|
| |
|
|
|
|
|
|
|
|
| |
When nested lambdas are used in NSDMI's - this prevents infinite recursion.
See http://llvm-reviews.chandlerc.com/D1783 for Doug's approval regarding the code, and then request for some tests.
[On a related note, I need this patch so as to pass tests of transformations of nested lambdas returned from member functions]
llvm-svn: 191645
|
| |
|
|
|
|
|
|
| |
cyclic GEP.
Those can occur in dead code. PR17402.
llvm-svn: 191644
|
| |
|
|
| |
llvm-svn: 191643
|
| |
|
|
| |
llvm-svn: 191642
|
| |
|
|
| |
llvm-svn: 191641
|
| |
|
|
| |
llvm-svn: 191640
|
| |
|
|
|
|
|
|
| |
Before, this could would lead to an assert:
llvm::errs() << "
<< a;
llvm-svn: 191639
|
| |
|
|
| |
llvm-svn: 191638
|
| |
|
|
| |
llvm-svn: 191637
|
| |
|
|
|
|
|
| |
SDNode destructors are never called. As an optimization use AtomicSDNode's
internal storage if we have a small number of operands.
llvm-svn: 191636
|
| |
|
|
| |
llvm-svn: 191635
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The general strategy is to create template versions of the conversion function and static invoker and then during template argument deduction of the conversion function, create the corresponding call-operator and static invoker specializations, and when the conversion function is marked referenced generate the body of the conversion function using the corresponding static-invoker specialization. Similarly, Codegen does something similar - when asked to emit the IR for a specialized static invoker of a generic lambda, it forwards emission to the corresponding call operator.
This patch has been reviewed in person both by Doug and Richard. Richard gave me the LGTM.
A few minor changes:
- per Richard's request i added a simple check to gracefully inform that captures (init, explicit or default) have not been added to generic lambdas just yet (instead of the assertion violation).
- I removed a few lines of code that added the call operators instantiated parameters to the currentinstantiationscope. Not only did it not handle parameter packs, but it is more relevant in the patch for nested lambdas which will follow this one, and fix that problem more comprehensively.
- Doug had commented that the original implementation strategy of using the TypeSourceInfo of the call operator to create the static-invoker was flawed and allowed const as a member qualifier to creep into the type of the static-invoker. I currently kludge around it - but after my initial discussion with Doug, with a follow up session with Richard, I have added a FIXME so that a more elegant solution that involves the use of TrivialTypeSourceInfo call followed by the correct wiring of the template parameters to the functionprototypeloc is forthcoming.
Thanks!
llvm-svn: 191634
|
| |
|
|
| |
llvm-svn: 191633
|
| |
|
|
|
|
| |
cases from switch.
llvm-svn: 191632
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Clang uses UTF-16 and UTF-32 for its char16_t's and char32_t's
exclusively. This means that we can define __STDC_UTF_16__ and
__STDC_UTF_32__ unconditionally.
While there, define __STDC_MB_MIGHT_NEQ_WC__ for FreeBSD. FreeBSD's
wchar_t's don't encode characters as ISO-10646; the encoding depends on
the locale used. Because the character set used might not be a superset
of ASCII, we must define __STDC_MB_MIGHT_NEQ_WC__.
llvm-svn: 191631
|
| |
|
|
| |
llvm-svn: 191630
|
| |
|
|
|
|
|
| |
instead, it's enabled by the -cc1 flag -fsized-deallocation, until we sort out
the backward-compatibility issues.
llvm-svn: 191629
|
| |
|
|
| |
llvm-svn: 191628
|
| |
|
|
| |
llvm-svn: 191627
|
| |
|
|
| |
llvm-svn: 191626
|
| |
|
|
|
|
| |
changes (yet)
llvm-svn: 191625
|
| |
|
|
|
|
|
| |
out in projects. This appears to be working on my system, and I will be
watching build bots to see if there are any issues on other platforms.
llvm-svn: 191624
|
| |
|
|
| |
llvm-svn: 191623
|
| |
|
|
|
|
| |
DependentScopeDeclRefExpr.
llvm-svn: 191622
|