Commit Graph

141 Commits

Author SHA1 Message Date
Duncan P. N. Exon Smith
13f5c5896d verify-uselistorder: Force -preserve-bc-use-list-order
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@216022 91177308-0d34-0410-b5e6-96231b3b80d8
2014-08-19 21:08:27 +00:00
Duncan P. N. Exon Smith
36c150801a verify-uselistorder: Call verifyModule() and improve output
Call `verifyModule()` after parsing and after every transformation.
Also convert some `DEBUG(dbgs())` to `errs()` to increase visibility
into what's going on.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@215951 91177308-0d34-0410-b5e6-96231b3b80d8
2014-08-18 23:44:14 +00:00
Duncan P. N. Exon Smith
1d8c9d95bf BitcodeReader: Only create one basic block for each blockaddress
Block address forward-references are implemented by creating a
`BasicBlock` ahead of time that gets inserted in the `Function` when
it's eventually encountered.

However, if the same blockaddress was used in two separate functions
that were parsed *before* the referenced function (and the blockaddress
was never used at global scope), two separate basic blocks would get
created, one of which would be forgotten creating invalid IR.

This commit changes the forward-reference logic to create only one basic
block (and always return the same blockaddress).

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@215805 91177308-0d34-0410-b5e6-96231b3b80d8
2014-08-16 01:54:37 +00:00
Duncan P. N. Exon Smith
49135bb76c Don't upgrade global constructors when reading bitcode
An optional third field was added to `llvm.global_ctors` (and
`llvm.global_dtors`) in r209015.  Most of the code has been changed to
deal with both versions of the variables.  Users of the C API might
create either version, the helper functions in LLVM create the two-field
version, and clang now creates the three-field version.

However, the BitcodeReader was changed to always upgrade to the
three-field version.  This created an unnecessary inconsistency in the
IR before/after serializing to bitcode.

This commit resolves the inconsistency by making the third field truly
optional (and not upgrading in the bitcode reader).  Since `llvm-link`
was relying on this upgrade code, rather than deleting it I've moved it
into `ModuleLinker`, where it upgrades these arrays as necessary to
resolve inconsistencies between modules.

The ideal resolution would be to remove the 2-field version and make the
third field required.  I filed PR20506 to track that.

I changed `test/Bitcode/upgrade-global-ctors.ll` to a negative test and
duplicated the `llvm-link` check in `test/Linker/global_ctors.ll` to
check both upgrade directions.

Since I came across this as part of PR5680 (serializing use-list order),
I've also added the missing `verify-uselistorder` RUN line to
`test/Bitcode/metadata-2.ll`.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@215457 91177308-0d34-0410-b5e6-96231b3b80d8
2014-08-12 16:46:37 +00:00
Duncan P. N. Exon Smith
1526278443 UseListOrder: Fix blockaddress use-list order
`parseBitcodeFile()` uses the generic `getLazyBitcodeFile()` function as
a helper.  Since `parseBitcodeFile()` isn't actually lazy -- it calls
`MaterializeAllPermanently()` -- bypass the unnecessary call to
`materializeForwardReferencedFunctions()` by extracting out a common
helper function.  This removes the last of the use-list churn caused by
blockaddresses.

This highlights that we can't reproduce use-list order of globals and
constants when parsing lazily -- but that's necessarily out of scope.
When we're parsing lazily, we never have all the functions in memory, so
the use-lists of globals (and constants that reference globals) are
always incomplete.

This is part of PR5680.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@214581 91177308-0d34-0410-b5e6-96231b3b80d8
2014-08-01 22:27:19 +00:00
Duncan P. N. Exon Smith
94f7c7aeaa verify-uselistorder: Change the default -num-shuffles=5
Change the default for `-num-shuffles` to 5 and better document the
algorithm in the header docs of `verify-uselistorder`.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@214419 91177308-0d34-0410-b5e6-96231b3b80d8
2014-07-31 18:46:24 +00:00
Duncan P. N. Exon Smith
9d65d3717c UseListOrder: Handle self-users
Correctly sort self-users (such as PHI nodes).  I added a targeted test
in `test/Bitcode/use-list-order.ll` and the final missing RUN line to
tests in `test/Assembly`.

This is part of PR5680.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@214417 91177308-0d34-0410-b5e6-96231b3b80d8
2014-07-31 18:33:12 +00:00
Duncan P. N. Exon Smith
e5ae09b08f UseListOrder: Don't give constant IDs to GlobalValues
Since initializers of GlobalValues are being assigned IDs before
GlobalValues themselves, explicitly exclude GlobalValues from the
constant pool.  Added targeted test in `test/Bitcode/use-list-order.ll`
and added two more RUN lines in `test/Assembly`.

This is part of PR5680.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@214368 91177308-0d34-0410-b5e6-96231b3b80d8
2014-07-31 00:13:28 +00:00
Rafael Espindola
d57120551f Use "weak alias" instead of "alias weak"
Before this patch we had

@a = weak global ...
but
@b = alias weak ...

The patch changes aliases to look more like global variables.

Looking at some really old code suggests that the reason was that the old
bison based parser had a reduction for alias linkages and another one for
global variable linkages. Putting the alias first avoided the reduce/reduce
conflict.

The days of the old .ll parser are long gone. The new one parses just "linkage"
and a later check is responsible for deciding if a linkage is valid in a
given context.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@214355 91177308-0d34-0410-b5e6-96231b3b80d8
2014-07-30 22:51:54 +00:00
Duncan P. N. Exon Smith
43b54db2a4 UseListOrder: Visit global values
When predicting use-list order, we visit functions in reverse order
followed by `GlobalValue`s and write out use-lists at the first
opportunity.  In the reader, this will translate to *after* the last use
has been added.

For this to work, we actually need to descend into `GlobalValue`s.
Added a targeted test in `use-list-order.ll` and `RUN` lines to the
newly passing tests in `test/Bitcode`.

There are two remaining failures in `test/Bitcode`:

  - blockaddress.ll: I haven't thought through how to model the way
    block addresses change the order of use-lists (or how to work around
    it).

  - metadata-2.ll: There's an old-style `@llvm.used` global array here
    that I suspect the .ll parser isn't upgrading properly.  When it
    round-trips through bitcode, the .bc reader *does* upgrade it, so
    the extra variable (`i8* null`) has an extra use, and the shuffle
    vector doesn't match.

    I think the fix is to upgrade old-style global arrays (or reject
    them?) in the .ll parser.

This is part of PR5680.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@214321 91177308-0d34-0410-b5e6-96231b3b80d8
2014-07-30 17:51:09 +00:00
Duncan P. N. Exon Smith
8dc3e30075 Fix line endings before adding RUN lines, NFC
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@214320 91177308-0d34-0410-b5e6-96231b3b80d8
2014-07-30 17:49:00 +00:00
Duncan P. N. Exon Smith
89c4197256 Rename llvm-uselistorder => verify-uselistorder
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@214318 91177308-0d34-0410-b5e6-96231b3b80d8
2014-07-30 17:11:27 +00:00
Duncan P. N. Exon Smith
cd29d80204 Reapply "UseListOrder: Order GlobalValue uses after initializers"
This reverts commit r214249, reapplying r214242 and r214243, now that
r214270 has fixed the UB.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@214271 91177308-0d34-0410-b5e6-96231b3b80d8
2014-07-30 01:22:16 +00:00
Duncan P. N. Exon Smith
70fec68744 Revert "UseListOrder: Order GlobalValue uses after initializers"
This reverts commits r214242 and r214243 while I investigate buildbot
failures [1][2][3].  I can't reproduce these failures locally, so if
anyone can see what I've done wrong, I'd appreciate a note.

[1]: http://lab.llvm.org:8011/builders/llvm-hexagon-elf/builds/9840
[2]: http://lab.llvm.org:8011/builders/clang-hexagon-elf/builds/14981
[3]: http://bb.pgr.jp/builders/cmake-llvm-x86_64-linux/builds/15191

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@214249 91177308-0d34-0410-b5e6-96231b3b80d8
2014-07-29 23:31:11 +00:00
Duncan P. N. Exon Smith
04bcdf16a9 UseListOrder: Additional test coverage for r214242
r214242 was subtle enough it really deserves a targeted test with
comments.  This adds some global variables that trigger the relevant
code path.  Sorry this wasn't committed with the fix.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@214243 91177308-0d34-0410-b5e6-96231b3b80d8
2014-07-29 23:15:49 +00:00
Duncan P. N. Exon Smith
9b9c19509f UseListOrder: Order GlobalValue uses after initializers
To avoid unnecessary forward references, the reader doesn't process
initializers of `GlobalValue`s until after the constant pool has been
processed, and then in reverse order.  Model this when predicting
use-list order.  This gets two more Bitcode tests passing with
`llvm-uselistorder`.

Part of PR5680.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@214242 91177308-0d34-0410-b5e6-96231b3b80d8
2014-07-29 23:06:14 +00:00
Duncan P. N. Exon Smith
994af148ca Bitcode: Correctly compare a Use against itself
Fix the sort of expected order in the reader to correctly return `false`
when comparing a `Use` against itself.

This was caught by test/Bitcode/binaryIntInstructions.3.2.ll, so I'm
adding a `RUN` line using `llvm-uselistorder` for every test in
`test/Bitcode` that passes.

A few tests still fail, so I'll investigate those next.

This is part of PR5680.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@214157 91177308-0d34-0410-b5e6-96231b3b80d8
2014-07-29 01:13:56 +00:00
Duncan P. N. Exon Smith
15f92a3a7d Fix line-endings, NFC
A follow-up commit is adding a RUN line to each of these tests, so fix
the line endings first.  This is a whitespace-only change.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@214156 91177308-0d34-0410-b5e6-96231b3b80d8
2014-07-29 01:10:57 +00:00
Duncan P. N. Exon Smith
a784589f57 llvm-uselistorder: Add -num-shuffles option
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@214144 91177308-0d34-0410-b5e6-96231b3b80d8
2014-07-28 23:25:21 +00:00
Duncan P. N. Exon Smith
bd24fe8c7e Bitcode: Serialize (and recover) use-list order
Predict and serialize use-list order in bitcode.  This makes the option
`-preserve-bc-use-list-order` work *most* of the time, but this is still
experimental.

  - Builds a full value-table up front in the writer, sets up a list of
    use-list orders to write out, and discards the table.  This is a
    simpler first step than determining the order from the various
    overlapping IDs of values on-the-fly.

  - The shuffles stored in the use-list order list have an unnecessarily
    large memory footprint.

  - `blockaddress` expressions cause functions to be materialized
    out-of-order.  For now I've ignored this problem, so use-list orders
    will be wrong for constants used by functions that have block
    addresses taken.  There are a couple of ways to fix this, but I
    don't have a concrete plan yet.

  - When materializing functions lazily, the use-lists for constants
    will not be correct.  This use case is out of scope: what should the
    use-list order be, if it's incomplete?

This is part of PR5680.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@214125 91177308-0d34-0410-b5e6-96231b3b80d8
2014-07-28 21:19:41 +00:00
Duncan P. N. Exon Smith
2602b66b91 Move -verify-use-list-order into llvm-uselistorder
Ugh.  Turns out not even transformation passes link in how to read IR.
I sincerely believe the buildbots will finally agree with my system
after this though.  (I don't really understand why all of this has been
working on my system, but not on all the buildbots.)

Create a new tool called llvm-uselistorder to use for verifying use-list
order.  For now, just dump everything from the (now defunct)
-verify-use-list-order pass into the tool.

This might be a better way to test use-list order anyway.

Part of PR5680.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@213957 91177308-0d34-0410-b5e6-96231b3b80d8
2014-07-25 17:13:03 +00:00
Duncan P. N. Exon Smith
7bf73bd378 IPO: Add use-list-order verifier
Add a -verify-use-list-order pass, which shuffles use-list order, writes
to bitcode, reads back, and verifies that the (shuffled) order matches.

  - The utility functions live in lib/IR/UseListOrder.cpp.

  - Moved (and renamed) the command-line option to enable writing
    use-lists, so that this pass can return early if the use-list orders
    aren't being serialized.

It's not clear that this pass is the right direction long-term (perhaps
a separate tool instead?), but short-term it's a great way to test the
use-list order prototype.  I've added an XFAIL-ed testcase that I'm
hoping to get working pretty quickly.

This is part of PR5680.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@213945 91177308-0d34-0410-b5e6-96231b3b80d8
2014-07-25 14:49:26 +00:00
Saleem Abdulrasool
e2c63ff3c9 AsmParser: remove deprecated LLIR support
linker_private and linker_private_weak were deprecated in 3.5.  Remove support
for them now that the 3.5 branch has been created.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@213777 91177308-0d34-0410-b5e6-96231b3b80d8
2014-07-23 18:09:31 +00:00
Hal Finkel
b3b2aac5be Make use of the align parameter attribute for all pointer arguments
We previously supported the align attribute on all (pointer) parameters, but we
only used it for byval parameters. However, it is completely consistent at the
IR level to treat 'align n' on all pointer parameters as an alignment
assumption on the pointer, and now we wll. Specifically, this causes
computeKnownBits to use the align attribute on all pointer parameters, not just
byval parameters. I've also added an explicit parameter attribute test for this
to test/Bitcode/attributes.ll.

And I've updated the LangRef to document the align parameter attribute (as it
turns out, it was not documented at all previously, although the byval
documentation mentioned that it could be used).

There are (at least) two benefits to doing this:
 - It allows enhancing alignment based on the pointer alignment after inlining callees.
 - It allows simplification of pointer arithmetic.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@213670 91177308-0d34-0410-b5e6-96231b3b80d8
2014-07-22 16:58:55 +00:00
Mark Heffernan
bc7f1aba2d Rename metadata llvm.loop.vectorize.unroll to llvm.loop.vectorize.interleave.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@213588 91177308-0d34-0410-b5e6-96231b3b80d8
2014-07-21 23:11:03 +00:00
Hal Finkel
11af4b49b2 Add a dereferenceable attribute
This attribute indicates that the parameter or return pointer is
dereferenceable. Practically speaking, loads from such a pointer within the
associated byte range are safe to speculatively execute. Such pointer
parameters are common in source languages (C++ references, for example).

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@213385 91177308-0d34-0410-b5e6-96231b3b80d8
2014-07-18 15:51:28 +00:00
Reid Kleckner
55a421f98d Roundtrip the inalloca bit on allocas through bitcode
This was an oversight in the original support.  As it is, I stuffed this
bit into the alignment.  The alignment is stored in log2 form, so it
doesn't need more than 5 bits, given that Value::MaximumAlignment is 1
<< 29.

Reviewers: nicholas

Differential Revision: http://reviews.llvm.org/D3943

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@213118 91177308-0d34-0410-b5e6-96231b3b80d8
2014-07-16 01:34:27 +00:00
Eli Bendersky
1ca9d7610d Add some test files for r211710.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@211711 91177308-0d34-0410-b5e6-96231b3b80d8
2014-06-25 15:41:39 +00:00
Tim Northover
8f2a85e099 IR: add "cmpxchg weak" variant to support permitted failure.
This commit adds a weak variant of the cmpxchg operation, as described
in C++11. A cmpxchg instruction with this modifier is permitted to
fail to store, even if the comparison indicated it should.

As a result, cmpxchg instructions must return a flag indicating
success in addition to their original iN value loaded. Thus, for
uniformity *all* cmpxchg instructions now return "{ iN, i1 }". The
second flag is 1 when the store succeeded.

At the DAG level, a new ATOMIC_CMP_SWAP_WITH_SUCCESS node has been
added as the natural representation for the new cmpxchg instructions.
It is a strong cmpxchg.

By default this gets Expanded to the existing ATOMIC_CMP_SWAP during
Legalization, so existing backends should see no change in behaviour.
If they wish to deal with the enhanced node instead, they can call
setOperationAction on it. Beware: as a node with 2 results, it cannot
be selected from TableGen.

Currently, no use is made of the extra information provided in this
patch. Test updates are almost entirely adapting the input IR to the
new scheme.

Summary for out of tree users:
------------------------------

+ Legacy Bitcode files are upgraded during read.
+ Legacy assembly IR files will be invalid.
+ Front-ends must adapt to different type for "cmpxchg".
+ Backends should be unaffected by default.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@210903 91177308-0d34-0410-b5e6-96231b3b80d8
2014-06-13 14:24:07 +00:00
Tom Roeder
5d0f7af3dc Add a new attribute called 'jumptable' that creates jump-instruction tables for functions marked with this attribute.
It includes a pass that rewrites all indirect calls to jumptable functions to pass through these tables.

This also adds backend support for generating the jump-instruction tables on ARM and X86.
Note that since the jumptable attribute creates a second function pointer for a
function, any function marked with jumptable must also be marked with unnamed_addr.


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@210280 91177308-0d34-0410-b5e6-96231b3b80d8
2014-06-05 19:29:43 +00:00
Rafael Espindola
2d21b25393 Allow alias to point to an arbitrary ConstantExpr.
This  patch changes GlobalAlias to point to an arbitrary ConstantExpr and it is
up to MC (or the system assembler) to decide if that expression is valid or not.

This reduces our ability to diagnose invalid uses and how early we can spot
them, but it also lets us do things like

@test5 = alias inttoptr(i32 sub (i32 ptrtoint (i32* @test2 to i32),
                                 i32 ptrtoint (i32* @bar to i32)) to i32*)

An important implication of this patch is that the notion of aliased global
doesn't exist any more. The alias has to encode the information needed to
access it in its metadata (linkage, visibility, type, etc).

Another consequence to notice is that getSection has to return a "const char *".
It could return a NullTerminatedStringRef if there was such a thing, but when
that was proposed the decision was to just uses "const char*" for that.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@210062 91177308-0d34-0410-b5e6-96231b3b80d8
2014-06-03 02:41:57 +00:00
Adam Nemet
0997206ac4 [X86] Move test from r209863 to CodeGen/X86
We should only run this if X86 is in the targets.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@209866 91177308-0d34-0410-b5e6-96231b3b80d8
2014-05-29 23:52:53 +00:00
Adam Nemet
23356d4d64 [X86] Auto-upgrade AVX1 vbroadcast intrinsics
They are replaced with the same IR that is generated for the
vector-initializers in avxintrin.h.

The test verifies that we get back the original instruction.  I haven't seen
this approach to be used in other auto-upgrade tests (i.e. llc + FileCheck)
but I think it's the most direct way to test this case.  I believe this should
work because llc upgrades calls during parsing.  (Other tests mostly check
that assembling and disassembling yields the upgraded IR.)

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@209863 91177308-0d34-0410-b5e6-96231b3b80d8
2014-05-29 23:35:33 +00:00
Nick Lewycky
fe47ebfad3 Add 'nonnull', a new parameter and return attribute which indicates that the pointer is not null. Instcombine will elide comparisons between these and null. Patch by Luqman Aden!
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@209185 91177308-0d34-0410-b5e6-96231b3b80d8
2014-05-20 01:23:40 +00:00
Rafael Espindola
e7a6c2f1df Handle ConstantAggregateZero when upgrading global_ctors.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@209075 91177308-0d34-0410-b5e6-96231b3b80d8
2014-05-17 21:00:22 +00:00
Rafael Espindola
27c076ae40 Fix most of PR10367.
This patch changes the design of GlobalAlias so that it doesn't take a
ConstantExpr anymore. It now points directly to a GlobalObject, but its type is
independent of the aliasee type.

To avoid changing all alias related tests in this patches, I kept the common
syntax

@foo = alias i32* @bar

to mean the same as now. The cases that used to use cast now use the more
general syntax

@foo = alias i16, i32* @bar.

Note that GlobalAlias now behaves a bit more like GlobalVariable. We
know that its type is always a pointer, so we omit the '*'.

For the bitcode, a nice surprise is that we were writing both identical types
already, so the format change is minimal. Auto upgrade is handled by looking
through the casts and no new fields are needed for now. New bitcode will
simply have different types for Alias and Aliasee.

One last interesting point in the patch is that replaceAllUsesWith becomes
smart enough to avoid putting a ConstantExpr in the aliasee. This seems better
than checking and updating every caller.

A followup patch will delete getAliasedGlobal now that it is redundant. Another
patch will add support for an explicit offset.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@209007 91177308-0d34-0410-b5e6-96231b3b80d8
2014-05-16 19:35:39 +00:00
Duncan P. N. Exon Smith
76c17d324c IR: Don't allow non-default visibility on local linkage
Visibilities of `hidden` and `protected` are meaningless for symbols
with local linkage.

  - Change the assembler to reject non-default visibility on symbols
    with local linkage.

  - Change the bitcode reader to auto-upgrade `hidden` and `protected`
    to `default` when the linkage is local.

  - Update LangRef.

<rdar://problem/16141113>

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@208263 91177308-0d34-0410-b5e6-96231b3b80d8
2014-05-07 22:57:20 +00:00
Reid Kleckner
710c1a449d Add 'musttail' marker to call instructions
This is similar to the 'tail' marker, except that it guarantees that
tail call optimization will occur.  It also comes with convervative IR
verification rules that ensure that tail call optimization is possible.

Reviewers: nicholas

Differential Revision: http://llvm-reviews.chandlerc.com/D3240

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@207143 91177308-0d34-0410-b5e6-96231b3b80d8
2014-04-24 20:14:34 +00:00
Saleem Abdulrasool
fa254cb46c AsmParser: add a warning for compatibility parsing
This adds a warning when linker_private or linker_private_weak is provided and
we handle it in a compatible manner.

Suggested by Chris Lattner!

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@205681 91177308-0d34-0410-b5e6-96231b3b80d8
2014-04-05 22:42:53 +00:00
Saleem Abdulrasool
48ee81c679 AsmParser: restore LLVM IR compatibility for linker_private{,_weak}
This restores the linker_private and linker_private_weak lexemes to permit
translation of the deprecated lexmes.  The behaviour is identical to the bitcode
handling: linker_private and linker_private_weak are handled as if private had
been specified.  This enables compatibility with IR generated by LLVM 3.4.

Reported on IRC by ki9a!

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@205675 91177308-0d34-0410-b5e6-96231b3b80d8
2014-04-05 20:51:58 +00:00
Karthik Bhat
6ac86cf119 All new elements except the last one initialized to NULL. Ideally, once parsing is complete, all elements should be non-NULL.
To safe-guard BitcodeReader, this patch adds null check for all access to these list.
Patch by Dinesh Dwivedi!


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@204920 91177308-0d34-0410-b5e6-96231b3b80d8
2014-03-27 12:08:23 +00:00
Rafael Espindola
1f21e0dd0d Remove the linker_private and linker_private_weak linkages.
These linkages were introduced some time ago, but it was never very
clear what exactly their semantics were or what they should be used
for. Some investigation found these uses:

* utf-16 strings in clang.
* non-unnamed_addr strings produced by the sanitizers.

It turns out they were just working around a more fundamental problem.
For some sections a MachO linker needs a symbol in order to split the
section into atoms, and llvm had no idea that was the case. I fixed
that in r201700 and it is now safe to use the private linkage. When
the object ends up in a section that requires symbols, llvm will use a
'l' prefix instead of a 'L' prefix and things just work.

With that, these linkages were already dead, but there was a potential
future user in the objc metadata information. I am still looking at
CGObjcMac.cpp, but at this point I am convinced that linker_private
and linker_private_weak are not what they need.

The objc uses are currently split in

* Regular symbols (no '\01' prefix). LLVM already directly provides
whatever semantics they need.
* Uses of a private name (start with "\01L" or "\01l") and private
linkage. We can drop the "\01L" and "\01l" prefixes as soon as llvm
agrees with clang on L being ok or not for a given section. I have two
patches in code review for this.
* Uses of private name and weak linkage.

The last case is the one that one could think would fit one of these
linkages. That is not the case. The semantics are

* the linker will merge these symbol by *name*.
* the linker will hide them in the final DSO.

Given that the merging is done by name, any of the private (or
internal) linkages would be a bad match. They allow llvm to rename the
symbols, and that is really not what we want. From the llvm point of
view, these objects should really be (linkonce|weak)(_odr)?.

For now, just keeping the "\01l" prefix is probably the best for these
symbols. If we one day want to have a more direct support in llvm,
IMHO what we should add is not a linkage, it is just a hidden_symbol
attribute. It would be applicable to multiple linkages. For example,
on weak it would produce the current behavior we have for objc
metadata. On internal, it would be equivalent to private (and we
should then remove private).

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@203866 91177308-0d34-0410-b5e6-96231b3b80d8
2014-03-13 23:18:37 +00:00
Tim Northover
ca396e391e IR: add a second ordering operand to cmpxhg for failure
The syntax for "cmpxchg" should now look something like:

	cmpxchg i32* %addr, i32 42, i32 3 acquire monotonic

where the second ordering argument gives the required semantics in the case
that no exchange takes place. It should be no stronger than the first ordering
constraint and cannot be either "release" or "acq_rel" (since no store will
have taken place).

rdar://problem/15996804

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@203559 91177308-0d34-0410-b5e6-96231b3b80d8
2014-03-11 10:48:52 +00:00
Michael Kuperstein
3de6ee1ae6 Ensure bitcode encoding of instructions and their operands stays stable.
This includes instructions that relate to memory access (load/store/GEP), comparison instructions and calls.

Work was done by lama.saba@intel.com.


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@202647 91177308-0d34-0410-b5e6-96231b3b80d8
2014-03-02 15:26:36 +00:00
Michael Kuperstein
2d0eef4c7d Ensure bitcode encoding of instructions and their operands stays stable.
This includes instructions with aggregate operands (insert/extract), instructions with vector operands (insert/extract/shuffle), binary arithmetic and bitwise instructions, conversion instructions and terminators.

Work was done by lama.saba@intel.com.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@202262 91177308-0d34-0410-b5e6-96231b3b80d8
2014-02-26 12:06:36 +00:00
Manman Ren
524f08d603 Update testing case for r200806.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@200807 91177308-0d34-0410-b5e6-96231b3b80d8
2014-02-04 23:53:12 +00:00
Manman Ren
2666b15908 Report a warning when dropping outdated debug info metadata.
Use DiagnosticInfo to emit the warning.


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@199346 91177308-0d34-0410-b5e6-96231b3b80d8
2014-01-16 01:51:12 +00:00
Nico Rieck
38f68c5a2e Decouple dllexport/dllimport from linkage
Representing dllexport/dllimport as distinct linkage types prevents using
these attributes on templates and inline functions.

Instead of introducing further mixed linkage types to include linkonce and
weak ODR, the old import/export linkage types are replaced with a new
separate visibility-like specifier:

  define available_externally dllimport void @f() {}
  @Var = dllexport global i32 1, align 4

Linkage for dllexported globals and functions is now equal to their linkage
without dllexport. Imported globals and functions must be either
declarations with external linkage, or definitions with
AvailableExternallyLinkage.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@199218 91177308-0d34-0410-b5e6-96231b3b80d8
2014-01-14 15:22:47 +00:00
Nico Rieck
55463f4ec1 Revert "Decouple dllexport/dllimport from linkage"
Revert this for now until I fix an issue in Clang with it.

This reverts commit r199204.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@199207 91177308-0d34-0410-b5e6-96231b3b80d8
2014-01-14 12:38:32 +00:00
Nico Rieck
bce07a0c3b Decouple dllexport/dllimport from linkage
Representing dllexport/dllimport as distinct linkage types prevents using
these attributes on templates and inline functions.

Instead of introducing further mixed linkage types to include linkonce and
weak ODR, the old import/export linkage types are replaced with a new
separate visibility-like specifier:

  define available_externally dllimport void @f() {}
  @Var = dllexport global i32 1, align 4

Linkage for dllexported globals and functions is now equal to their linkage
without dllexport. Imported globals and functions must be either
declarations with external linkage, or definitions with
AvailableExternallyLinkage.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@199204 91177308-0d34-0410-b5e6-96231b3b80d8
2014-01-14 11:55:03 +00:00