On x86, shifting a vector by a scalar is significantly cheaper than shifting a
vector by another fully general vector. Unfortunately, because SelectionDAG
operates on just one basic block at a time, the shufflevector instruction that
reveals whether the right-hand side of a shift *is* really a scalar is often
not visible to CodeGen when it's needed.
This adds another handler to CodeGenPrepare, to sink any useful shufflevector
instructions down to the basic block where they're used, predicated on a target
hook (since on other architectures, doing so will often just introduce extra
real work).
rdar://problem/16063505
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@201655 91177308-0d34-0410-b5e6-96231b3b80d8
Load Configuration Table may contain a pointer to SEH table. This patch is to
print the offset to the table. Printing SEH table contents is a TODO.
The layout of Layout Configuration Table is described in Microsoft PE/COFF
Object File Format Spec, but the table's offset/size descriptions seems to be
totally wrong, at least in revision 8.3 of the spec. I believe the table in
this patch is the correct one.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@201638 91177308-0d34-0410-b5e6-96231b3b80d8
This enhances the macro parser to parse and handle parameter qualifications,
which is needed to support required formal parameters in macro definitions. A
required parameter may not be defaulted (though providing a default value is
accepted with a warning). This improves GAS compatibility.
Partially addresses PR9248.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@201630 91177308-0d34-0410-b5e6-96231b3b80d8
Rather than using std::pair, create a structure to represent the type. This is
a preliminary refactoring to enable required parameter handling. Additional
state is needed to indicate required parameters. This has a minor side effect
of improving readability by providing more accurate names compared to first and
second.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@201629 91177308-0d34-0410-b5e6-96231b3b80d8
When outputting an object we check its section to find its name, but when
looking for the section with -ffunction-section we look for the symbol name.
Break the loop by requesting a name with the private prefix when constructing
the section name. This matches the behavior before r201608.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@201622 91177308-0d34-0410-b5e6-96231b3b80d8
Some references to llvm-gcc were so crusty that I wasn't sure how to
proceed and so I've left them intact.
I also slipped in a quick peephole fix to use a :doc: link instead of
raw HTML link.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@201619 91177308-0d34-0410-b5e6-96231b3b80d8
From a cursory look it seems like all the described commandline options
and such apply to clang just fine, but I'd appreciate a second opinion.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@201616 91177308-0d34-0410-b5e6-96231b3b80d8
The IR
@foo = private constant i32 42
is valid, but before this patch we would produce an invalid MachO from it. It
was invalid because it would use an L label in a section where the liker needs
the labels in order to atomize it.
One way of fixing it would be to just reject this IR in the backend, but that
would not be very front end friendly.
What this patch does is use an 'l' prefix in sections that we know the linker
requires symbols for atomizing them. This allows frontends to just use
private and not worry about which sections they go to or how the linker handles
them.
One small issue with this strategy is that now a symbol name depends on the
section, which is not available before codegen. This is not a problem in
practice. The reason is that it only happens with private linkage, which will
be ignored by the non codegen users (llvm-nm and llvm-ar).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@201608 91177308-0d34-0410-b5e6-96231b3b80d8
findOrEmitSection).
Vaidas Gasiunas's patch, r201259, fixed one instance where we were always
allocating sections as text. This patch fixes the remaining buggy call sites.
No test case: This isn't breaking anything that I know of, it's just
inconsistent.
<rdar://problem/15943542>
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@201605 91177308-0d34-0410-b5e6-96231b3b80d8
BuildMI instructions were not including MachineMemOperand information.
This was discovered by 'SingleSource/Benchmarks/Stanford/Oscar' failing
due to a FrameIndex load incorrectly being hoisted by postra-machine-licm.
No other tests have been found to fail.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@201562 91177308-0d34-0410-b5e6-96231b3b80d8
Modifying build_llvm to handle SDKROOT being the name of an SDK rather than a
path. This will still work if SDKROOT is a path.
rdar://problem/15162322
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@201560 91177308-0d34-0410-b5e6-96231b3b80d8
In gcov, the -o flag can accept either a directory or a file name.
When given a directory, the gcda and gcno files are expected to be in
that directory. When given a file, the gcda and gcno files are
expected to be named based on the stem of that file. Non-existent
paths are treated as files.
This implements compatible behaviour.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@201555 91177308-0d34-0410-b5e6-96231b3b80d8
Introducing llvm-profdata, a tool for merging profile data generated by
PGO instrumentation in clang.
- The name indicates a file extension of <name>.profdata. Eventually
profile data output by clang should be changed to that extension.
- llvm-profdata merges two profiles. However, the name is more general,
since it will likely pick up more tasks (such as summarizing a single
profile).
- llvm-profdata parses the current text-based format, but will be
updated once we settle on a binary format.
<rdar://problem/15949645>
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@201535 91177308-0d34-0410-b5e6-96231b3b80d8
ldrd r6, r7 [r2, #15]
simply gives an error and does not triggers an assertion.
As Jim points out, the diagnostic is really strange here,
but fixing that would be more complicated. The missing
comma results in the parser expecting a construct like r2[2],
which is the vector index thing the error message is talking
about. That's not what the user intended, though, and there's
nothing else in the instruction that looks at all like a vector.
Yet more fallout from not having a real parser here and trying
to do context-free generic matching for addressing modes.
rdar://15097243
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@201531 91177308-0d34-0410-b5e6-96231b3b80d8
