| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
| |
related. NFC.
Eric has replied and has demanded the patch be reverted.
llvm-svn: 247702
|
|
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D10537
llvm-svn: 247697
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
and related. NFC.
Summary:
This is the first patch in the series to migrate Triple's (which are ambiguous)
to TargetTuple's (which aren't).
For the moment, TargetTuple simply passes all requests to the Triple object it
holds. Once it has replaced Triple, it will start to implement the interface in
a more suitable way.
This change makes some changes to the public C++ API. In particular,
InitMCSubtargetInfo(), createMCRelocationInfo(), and createMCSymbolizer()
now take TargetTuples instead of Triples. The other public C++ API's have
been left as-is for the moment to reduce patch size.
This commit also contains a trivial patch to clang to account for the C++ API
change. Thanks go to Pavel Labath for fixing LLDB for me.
Reviewers: rengolin
Subscribers: jyknight, dschuff, arsenm, rampitec, danalbert, srhines, javed.absar, dsanders, echristo, emaste, jholewinski, tberghammer, ted, jfb, llvm-commits, rengolin
Differential Revision: http://reviews.llvm.org/D10969
llvm-svn: 247692
|
|
|
|
|
|
| |
LLDB needs to be updated in the same commit.
llvm-svn: 247686
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This is the first patch in the series to migrate Triple's (which are ambiguous)
to TargetTuple's (which aren't).
For the moment, TargetTuple simply passes all requests to the Triple object it
holds. Once it has replaced Triple, it will start to implement the interface in
a more suitable way.
This change makes some changes to the public C++ API. In particular,
InitMCSubtargetInfo(), createMCRelocationInfo(), and createMCSymbolizer()
now take TargetTuples instead of Triples. The other public C++ API's have
been left as-is for the moment to reduce patch size.
This commit also contains a trivial patch to clang to account for the C++ API
change.
Reviewers: rengolin
Subscribers: jyknight, dschuff, arsenm, rampitec, danalbert, srhines, javed.absar, dsanders, echristo, emaste, jholewinski, tberghammer, ted, jfb, llvm-commits, rengolin
Differential Revision: http://reviews.llvm.org/D10969
llvm-svn: 247683
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
operands, NFC.
Summary:
These operands had the same purpose, however the MipsMemSimm9GPRAsmOperand
operand was only for micromips32r6 and the MipsMemSimm9AsmOperand did not
have a ParserMatchClass.
Patch by Scott Egerton
Reviewers: vkalintiris, dsanders
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D12730
llvm-svn: 247573
|
|
|
|
| |
llvm-svn: 247547
|
|
|
|
|
|
|
|
| |
16-bit LBU16, LHU16, LW16, LWGP and LWSP instructions
Differential Revision: http://reviews.llvm.org/D10956
llvm-svn: 246987
|
|
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D11181
llvm-svn: 246963
|
|
|
|
| |
llvm-svn: 246953
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
traps and breaks in the integrated assembler.
Summary:
Patch by Scott Egerton
Reviewers: vkalintiris, dsanders
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D11675
llvm-svn: 246763
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: This is the correct way to handle JAL instructions when PIC is enabled.
Patch by Toma Tabacu
Reviewers: seanbruno, tomatabacu
Subscribers: brooks, seanbruno, emaste, llvm-commits
Differential Revision: http://reviews.llvm.org/D6231
llvm-svn: 245305
|
|
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D10869
llvm-svn: 245293
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
or not.
Summary:
This information is needed to decide whether we do the PIC-only JAL expansions or not. It's also needed for an upcoming patch which implements the .cprestore assembler directive (which can only be used effectively in PIC mode).
By making this information available to the MipsAsmParser, we will know when to insert the instructions mandated by the .cprestore assembler directive and we will be able to give some useful warnings when we encounter a potential misuse of this directive.
Patch by Toma Tabacu
Reviewers: dsanders, seanbruno
Subscribers: brooks, seanbruno, rafael, llvm-commits
Differential Revision: http://reviews.llvm.org/D5626
llvm-svn: 245291
|
|
|
|
|
|
|
|
| |
the constant.
This was supposed to have been committed as part of r245208
llvm-svn: 245285
|
|
|
|
|
|
| |
constant conversion.
llvm-svn: 245220
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
with DLI
Summary: It is the same as LA, except that it can also load 64-bit addresses and it only works on 64-bit MIPS architectures.
Reviewers: tomatabacu, seanbruno, vkalintiris
Subscribers: brooks, seanbruno, emaste, llvm-commits
Differential Revision: http://reviews.llvm.org/D9524
llvm-svn: 245208
|
|
|
|
| |
llvm-svn: 243334
|
|
|
|
|
|
| |
'int16_t' and truncation of constant value. NFC intended.
llvm-svn: 242145
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
- Signed 16-bit should have priority over unsigned.
- For la, unsigned 16-bit must use ori+addu rather than directly use ori.
- Correct tests on 32-bit immediates with 64-bit predicates by
sign-extending the immediate beforehand. For example, isInt<16>(0xffff8000)
should be true and use addiu.
Also split li/la testing into separate files due to their size.
Reviewers: vkalintiris
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D10967
llvm-svn: 242139
|
|
|
|
|
|
|
|
|
| |
These directives are used to set the default value of the SoftFloat feature.
They have the same effect as setting -m{soft, hard}-float from the command line.
Differential Revision: http://reviews.llvm.org/D9073
llvm-svn: 241066
|
|
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D10643
llvm-svn: 241062
|
|
|
|
| |
llvm-svn: 241061
|
|
|
|
|
|
|
|
|
| |
represented by uint64_t, this patch replaces these
usages with the FeatureBitset (std::bitset) type.
Differential Revision: http://reviews.llvm.org/D10542
llvm-svn: 241058
|
|
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D10657
llvm-svn: 241052
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Previously it (incorrectly) used GPR's.
Patch by Simon Dardis. A couple small corrections by myself.
Reviewers: dsanders
Reviewed By: dsanders
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D10567
llvm-svn: 240883
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This only adds support for ULW of an immediate address with/without a source register.
It does not include support for ULW of the address of a symbol.
Reviewers: dsanders
Reviewed By: dsanders
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D9663
llvm-svn: 240782
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Simplify emitDirectiveModuleFP() by having it just print the current information
from MipsABIFlagsSection and doing an updateABIInfo() before such calls.
This prevents us from forgetting to update the STI.FeatureBits,
because updateABIInfo() uses those to update the MipsABIFlagsSection object,
and also makes sure we use the update mechanism from MipsABIFlagsSection.
Reviewers: dsanders
Reviewed By: dsanders
Subscribers: llvm-commits, mpf
Differential Revision: http://reviews.llvm.org/D10642
llvm-svn: 240637
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
We can simplify emitDirectiveModuleOddSPReg() by having it print the current OddSPReg information
from MipsABIFlagsSection and doing an updateABIInfo() before such calls.
This prevents us from forgetting to update the STI.FeatureBits, because updateABIInfo() uses those to update the MipsABIFlagsSection object,
and also makes sure we use the update mechanism from MipsABIFlagsSection.
Reviewers: dsanders
Reviewed By: dsanders
Subscribers: llvm-commits, mpf
Differential Revision: http://reviews.llvm.org/D10641
llvm-svn: 240630
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
In an expression such as "(((a+b)+c)+d)", parseParenExpression() would only parse the "a+b)+c", which would result in an error later on in the parser.
This means that we can only parse one level of inner parentheses.
In order to fix this, I added a new function called parseParenExprOfDepth(), which parses a specified number of trailing parenthesis expressions
(except for the outermost parenthesis), and changed MipsAsmParser to use it in parseMemOffset instead of parseParenExpression().
Reviewers: dsanders, rafael
Reviewed By: dsanders, rafael
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D9742
llvm-svn: 240625
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This only adds support for ULHU of an immediate address with/without a source register.
It does not include support for ULHU of the address of a symbol.
Reviewers: dsanders
Reviewed By: dsanders
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D9671
llvm-svn: 240410
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: This isn't used right now, but it will be in some upcoming changes.
Reviewers: dsanders
Reviewed By: dsanders
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D10568
llvm-svn: 240407
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
register operands.
Summary: In this case, we're supposed to load the immediate in AT and then ADDu it with the source register and put it in the destination register.
Reviewers: dsanders
Reviewed By: dsanders
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D9367
llvm-svn: 240278
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
register operands.
Summary:
In this case, we're supposed to load the address of the symbol in AT and then ADDu it with the source register and
put it in the destination register.
Reviewers: dsanders
Reviewed By: dsanders
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D9366
llvm-svn: 240273
|
|
|
|
|
|
|
|
|
|
|
|
| |
Reviewers: dsanders
Reviewed By: dsanders
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D9348
llvm-svn: 239910
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This does not include support for the immediate variants of these pseudo-instructions.
Fixes llvm.org/PR20968.
Reviewers: dsanders
Reviewed By: dsanders
Subscribers: seanbruno, emaste, llvm-commits
Differential Revision: http://reviews.llvm.org/D8537
llvm-svn: 239905
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Call MCSymbolRefExpr::create() with a MCSymbol* argument, not with a StringRef
of the Symbol's name, in order to avoid creating invalid temporary symbols for
relative labels (e.g. {$,.L}tmp00, {$,.L}tmp10 etc.).
Reviewers: dsanders
Reviewed By: dsanders
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D10498
llvm-svn: 239901
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Previously, MCSymbolRefExpr::create() was called with a StringRef of the symbol
name, which it would then search for in the Symbols StringMap (from MCContext).
However, relative labels (which are temporary symbols) are apparently not stored
in the Symbols StringMap, so we end up creating a new {$,.L}tmp symbol
({$,.L}tmp00, {$,.L}tmp10 etc.) each time we create an MCSymbolRefExpr by
passing in the symbol name as a StringRef.
Fortunately, there is a version of MCSymbolRefExpr::create() which takes an
MCSymbol* and we already have an MCSymbol* at that point, so we can just pass
that in instead of the StringRef.
I also removed the local StringRef calls to MCSymbolRefExpr::create() from
expandMemInst(), as those cases can be handled by evaluateRelocExpr() anyway.
Reviewers: dsanders
Reviewed By: dsanders
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D9938
llvm-svn: 239897
|
|
|
|
|
|
|
|
|
|
|
|
| |
Reviewers: dsanders
Reviewed By: dsanders
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D9523
llvm-svn: 239811
|
|
|
|
|
|
|
|
|
| |
operand." (r239396).
Apparently, Arcanist didn't include some of my local changes in my previous
commit attempt.
llvm-svn: 239523
|
|
|
|
|
|
| |
http://reviews.llvm.org/D10312
llvm-svn: 239520
|
|
|
|
|
|
|
| |
Specified the llvm namespace for the 2 calls to make_unique() which caused
compilation errors in Visual Studio 2013.
llvm-svn: 239405
|
|
|
|
|
|
|
|
| |
(r239396).
It was breaking buildbots.
llvm-svn: 239397
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
For some branches, GAS accepts an immediate instead of the 2nd register operand.
We only implement this for BNE and BEQ for now. Other branch instructions can be added later, if needed.
Reviewers: dsanders
Reviewed By: dsanders
Subscribers: seanbruno, emaste, llvm-commits
Differential Revision: http://reviews.llvm.org/D9666
llvm-svn: 239396
|
|
|
|
|
|
| |
This is breaking the Windows buildbots.
llvm-svn: 239145
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Only restoring AvailableFeatures is not enough and will lead to buggy behaviour.
For example, if we have a feature enabled and we ".set pop", the next time we try
to ".set" that feature nothing will happen because the "!(STI.getFeatureBits()[Feature])"
check will be false, because we didn't restore STI.FeatureBits.
In order to fix this, we need to make MipsAssemblerOptions remember the STI.FeatureBits
instead of the AvailableFeatures and then regenerate AvailableFeatures each time we ".set pop".
This is because, AFAIK, there is no way to convert from AvailableFeatures back to STI.FeatureBits,
but the reverse is possible by using ComputeAvailableFeatures(STI.FeatureBits).
I also moved the updating of AssemblerOptions inside the "if" statement in
setFeatureBits() and clearFeatureBits(), as there is no reason to update if
nothing changes.
Reviewers: dsanders, mkuper
Reviewed By: dsanders
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D9156
llvm-svn: 239144
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: These directives are used to set the current value of the SoftFloat feature.
Reviewers: dsanders
Reviewed By: dsanders
Subscribers: llvm-commits, mpf
Differential Revision: http://reviews.llvm.org/D9074
llvm-svn: 238813
|
|
|
|
| |
llvm-svn: 238634
|
|
|
|
| |
llvm-svn: 238315
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously, subtarget features were a bitfield with the underlying type being uint64_t.
Since several targets (X86 and ARM, in particular) have hit or were very close to hitting this bound, switching the features to use a bitset.
No functional change.
The first several times this was committed (e.g. r229831, r233055), it caused several buildbot failures.
Apparently the reason for most failures was both clang and gcc's inability to deal with large numbers (> 10K) of bitset constructor calls in tablegen-generated initializers of instruction info tables.
This should now be fixed.
llvm-svn: 238192
|