This Disassembly support allows for 'round-trip' testing, and rv32i-valid.s
has been updated appropriately.
Differential Revision: https://reviews.llvm.org/D23567
llvm-svn: 313486
This patch supports all RV32I instructions as described in the RISC-V manual.
A future patch will add support for pseudoinstructions and other instruction
expansions (e.g. 0-arg fence -> fence iorw, iorw).
Differential Revision: https://reviews.llvm.org/D23566
llvm-svn: 313485
It doesn't make sense to me why these bots are failing as the
traceback does not agree with the source code. It's possible
something is stale or there is some other mysterious error,
but in any case hopefully this fixes it.
llvm-svn: 313469
This was a bug in the test that was only exposed as a result of
refactoring some code in lit configuration files. Previously,
llvm's lit configuration would only set the target-windows feature
if the system was also windows. Since cross-compilation is
a thing, this isn't correct. target-windows should be set
independently of system-windows.
Adding to that bug, this particular test then checked for
target-windows when it really meant "can I call a certain API on
the host machine", which is what system-windows is for.
Ultimately, this test only works if *both* the target and host
are Windows, so I've updated the test to reflect that.
llvm-svn: 313468
The same code appears earlier in the function. This represents an earlier version of what became r313373 that I still had sitting in my local repo.
llvm-svn: 313465
Summary:
For a lot of older CPUs we have a 1:1 mapping between CPU name and enum name. But many of them are effectively aliases of each other and as a result are always repeated together at every usage
This patch removes most of the duplication. It also uses StringSwitch::Cases to make the many to one mapping in the StringSwitch more obvious.
Reviewers: RKSimon, spatel, zvi, igorb
Reviewed By: RKSimon
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D37938
llvm-svn: 313462
A few tests were manually constructing a LitConfig object, since
I added a new argument to it this was triggering some failures
I didn't detect. `ninja check-lit` passes now.
llvm-svn: 313461
This is helpful for debugging test failures since it removes
the multiprocessing pool from the picture. This will obviously
slow down the test suite by a few orders of magnitude, so it
should only be used for debugging specific failures.
llvm-svn: 313460
readelf tool reports an error when output contains the same section
in multiple COMDAT groups. That can be useful.
Path teaches llvm-readobj to do the same.
Differential revision: https://reviews.llvm.org/D37567
llvm-svn: 313459
This allows vector-sized store merging of constants in DAGCombiner using the existing code in MergeConsecutiveStores().
All of the twisted logic that decides exactly what vector operations are legal and fast for each particular CPU are
handled separately in there using the appropriate hooks.
For the motivating tests in merge-store-constants.ll, we already produce the same vector code in IR via the SLP vectorizer.
So this is just providing a backend backstop for code that doesn't go through that pass (-O1). More details in PR24449:
https://bugs.llvm.org/show_bug.cgi?id=24449 (this change should be the last step to resolve that bug)
Differential Revision: https://reviews.llvm.org/D37451
llvm-svn: 313458
We just need to toggle bits 1 and 5 of the immediate and swap the sources. The peephole pass could trigger commuting/folding for this later, but its easy enough to fix in isel.
Disable the peephole pass on the main vperm2x128 test so we know we're doing this through isel.
llvm-svn: 313455
I've moved the test cases from the InstCombine optimizations to the backend to keep the coverage we had there. It covered every possible immediate so I've preserved the resulting shuffle mask for each of those immediates.
llvm-svn: 313450
OpenOCD sends register classes as two separate <feature> nodes, fixed parser to process both of them.
OpenOCD returns "l" in response to "qfThreadInfo", so IsUnsupportedResponse() was false and we were ending up without any threads in the process. I think it's reasonable to assume that there's always at least one thread.
llvm-svn: 313442
Alex Bradbury