Commit Graph

216 Commits

Author SHA1 Message Date
Rafael Espindola
9afb3a2589 Fix for PR23310: llvm-dis crashes when trying to upgrade an intrinsic.
When trying to upgrade @llvm.x86.sse2.psrl.dq while parsing a module,
BitcodeReader adds the function to its worklist twice, resulting in a
crash when accessing it the second time.

This patch replaces the worklist vector by a map.

Patch by Philip Pfaffe.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@241281 91177308-0d34-0410-b5e6-96231b3b80d8
2015-07-02 16:22:40 +00:00
David Majnemer
cc714e2142 Move the personality function from LandingPadInst to Function
The personality routine currently lives in the LandingPadInst.

This isn't desirable because:
- All LandingPadInsts in the same function must have the same
  personality routine.  This means that each LandingPadInst beyond the
  first has an operand which produces no additional information.

- There is ongoing work to introduce EH IR constructs other than
  LandingPadInst.  Moving the personality routine off of any one
  particular Instruction and onto the parent function seems a lot better
  than have N different places a personality function can sneak onto an
  exceptional function.

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

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@239940 91177308-0d34-0410-b5e6-96231b3b80d8
2015-06-17 20:52:32 +00:00
Rafael Espindola
0c650627ca Improve handling of end of file in the bitcode reader.
Before this patch the bitcode reader would read a module from a file
that contained in order:

* Any number of non MODULE_BLOCK sub blocks.
* One MODULE_BLOCK
* Any number of non MODULE_BLOCK sub blocks.
* 4 '\n' characters to handle OS X's ranlib.

Since we support lazy reading of modules, any information that is relevant
for the module has to be in the MODULE_BLOCK or before it. We don't gain
anything from checking what is after.

This patch then changes the reader to stop once the MODULE_BLOCK has been
successfully parsed.

This avoids the ugly special case for .bc files in an archive and makes it
easier to embed bitcode files.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@239845 91177308-0d34-0410-b5e6-96231b3b80d8
2015-06-16 20:03:39 +00:00
Rafael Espindola
0021a54ae5 Add a test for padded bitcode files.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@239829 91177308-0d34-0410-b5e6-96231b3b80d8
2015-06-16 16:36:15 +00:00
Filipe Cabecinhas
a3a2cab504 [BitcodeReader] Diagnose type mismatches with aliases
Bug found with AFL fuzz.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@238895 91177308-0d34-0410-b5e6-96231b3b80d8
2015-06-03 01:30:13 +00:00
Filipe Cabecinhas
1a2a0ee8a0 [Bitcode] Minimize the test to not conflict with others
Source for the test:
@bloom = global <3 x i32> <i32 0, i32 1, i32 42>

Plus bit twiddling to set the vector numelts to 0 (in the bc file).

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@238894 91177308-0d34-0410-b5e6-96231b3b80d8
2015-06-03 01:30:08 +00:00
Filipe Cabecinhas
287f68d654 [BitcodeReader] Check vector size before trying to create a VectorType
Bug found with AFL fuzz

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@238891 91177308-0d34-0410-b5e6-96231b3b80d8
2015-06-03 00:05:30 +00:00
Filipe Cabecinhas
3b821159da [BitcodeReader] Change an assert to a call to a call to Error()
It's reachable from user input.

Bug found with AFL fuzz.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@238633 91177308-0d34-0410-b5e6-96231b3b80d8
2015-05-30 00:17:20 +00:00
Filipe Cabecinhas
1c0b496636 [BitcodeReader] Change assert to report_fatal_error
It can be triggered by user input.

Bug found with AFL fuzz.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@238272 91177308-0d34-0410-b5e6-96231b3b80d8
2015-05-27 01:05:40 +00:00
Filipe Cabecinhas
316f9e05ce [BitstreamReader] Make sure the Array operand type is an encoding
Bug found with AFL fuzz.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@238269 91177308-0d34-0410-b5e6-96231b3b80d8
2015-05-27 00:48:43 +00:00
Filipe Cabecinhas
c756772b8d [BitcodeReader] Make sure abbrev records have at least one operand (record code)
Bug found with AFL fuzz.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@238265 91177308-0d34-0410-b5e6-96231b3b80d8
2015-05-26 23:52:21 +00:00
Owen Anderson
13146c7e3b Add initial support for the convergent attribute.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@238264 91177308-0d34-0410-b5e6-96231b3b80d8
2015-05-26 23:48:40 +00:00
Filipe Cabecinhas
1c74d4768a [BitcodeReader] Sanity check on Comdat ID
Shouldn't be an assert, since user input can trigger it.

Bug found with AFL fuzz.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@238261 91177308-0d34-0410-b5e6-96231b3b80d8
2015-05-26 23:00:56 +00:00
Adrian Prantl
849c7601a0 IR / debug info: Add a DWOId field to DICompileUnit,
so DWARF skeleton CUs can be expression in IR. A skeleton CU is a
(typically empty) DW_TAG_compile_unit that has a DW_AT_(GNU)_dwo_name and
a DW_AT_(GNU)_dwo_id attribute. It is used to refer to external debug info.

This is a prerequisite for clang module debugging as discussed in
http://lists.cs.uiuc.edu/pipermail/cfe-dev/2014-November/040076.html.
In order to refer to external types stored in split DWARF (dwo) objects,
such as clang modules, we need to emit skeleton CUs, which identify the
dwarf object (i.e., the clang module) by filename (the SplitDebugFilename)
and a hash value, the dwo_id.

This patch only contains the IR changes. The idea is that a CUs with a
non-zero dwo_id field will be emitted together with a DW_AT_GNU_dwo_name
and DW_AT_GNU_dwo_id attribute.

http://reviews.llvm.org/D9488
rdar://problem/20091852

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@237949 91177308-0d34-0410-b5e6-96231b3b80d8
2015-05-21 20:37:30 +00:00
Filipe Cabecinhas
27ca64f3d3 Change a reachable unreachable to a fatal error.
Summary:
Also tagged a FIXME comment, and added information about why it breaks.

Bug found using AFL fuzz.

Reviewers: rafael, craig.topper

Subscribers: llvm-commits

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

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@237709 91177308-0d34-0410-b5e6-96231b3b80d8
2015-05-19 18:18:10 +00:00
Filipe Cabecinhas
bf27e11e02 [BitcodeReader] Error out if we read an invalid function argument type
Bug found with AFL fuzz.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@237650 91177308-0d34-0410-b5e6-96231b3b80d8
2015-05-19 01:21:06 +00:00
Filipe Cabecinhas
c3ccd67d72 [BitcodeReader] It's a malformed block if CodeLenWidth is too big
Bug found with AFL fuzz.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@237646 91177308-0d34-0410-b5e6-96231b3b80d8
2015-05-19 00:34:17 +00:00
Filipe Cabecinhas
b2bf278152 [BitcodeReader] Make sure the type of the inserted value matches the type of the aggregate at those indices
Bug found with AFL-fuzz.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@237628 91177308-0d34-0410-b5e6-96231b3b80d8
2015-05-18 22:27:11 +00:00
Filipe Cabecinhas
70a2c7260a Extract the load/store type verification to a separate function.
Summary:
Added isLoadableOrStorableType to PointerType.

We were doing some checks in some places, occasionally assert()ing instead
of telling the caller. With this patch, I'm putting all type checking in
the same place for load/store type instructions, and verifying the same
thing every time.

I also added a check for load/store of a function type.

Applied extracted check to Load, Store, and Cmpxcg.

I don't have exhaustive tests for all of these, but all Error() calls in
TypeCheckLoadStoreInst are being tested (in invalid.test).

Reviewers: dblaikie, rafael

Subscribers: llvm-commits

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

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@237619 91177308-0d34-0410-b5e6-96231b3b80d8
2015-05-18 21:48:55 +00:00
Filipe Cabecinhas
ddf553bb8d [BitcodeReader] Don't allow INSERTVAL/EXTRACTVAL with 0 indices
This would trigger an assertion later.

Bug found with AFL fuzz.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@237494 91177308-0d34-0410-b5e6-96231b3b80d8
2015-05-16 00:33:12 +00:00
Duncan P. N. Exon Smith
6cc81efe93 Bitcode: Set LastDL after writing DebugLocs
Somehow I dropped this in r233585, and we haven't had `DEBUG_LOC_AGAIN`
records since.  Add it back.  Also tests that the output assembly looks
okay.

Fixes PR23436.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@236661 91177308-0d34-0410-b5e6-96231b3b80d8
2015-05-06 22:51:12 +00:00
Filipe Cabecinhas
deedba2a36 Don't overflow GCTable
Summary: Bug found with AFL fuzz.

Reviewers: rafael, dexonsmith

Subscribers: llvm-commits

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

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@236200 91177308-0d34-0410-b5e6-96231b3b80d8
2015-04-30 04:09:41 +00:00
Filipe Cabecinhas
8b2199e2a2 Make sure Op->getType() is a PointerType before we cast<> it.
Bug found with AFL fuzz.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@236193 91177308-0d34-0410-b5e6-96231b3b80d8
2015-04-30 01:13:31 +00:00
Filipe Cabecinhas
a607be94ca Make sure we don't resize(0) when we get a fwdref with Idx == UINT_MAX
Make it an error instead.

Bug found with AFL fuzz.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@236190 91177308-0d34-0410-b5e6-96231b3b80d8
2015-04-30 00:52:42 +00:00
Filipe Cabecinhas
99ebc9e004 Check that we have a valid PointerType element type before calling get()
Same as r236073 but for PointerType.

Bug found with AFL fuzz.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@236079 91177308-0d34-0410-b5e6-96231b3b80d8
2015-04-29 02:27:28 +00:00
Filipe Cabecinhas
7b30f32d3d Turn an assert into report_fatal_error since it's reachable based on user input
Bug found with AFL fuzz.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@236076 91177308-0d34-0410-b5e6-96231b3b80d8
2015-04-29 01:58:31 +00:00
Filipe Cabecinhas
3b4a565b8a Make sure that isValidElementType(Type) before calling {Array,Struct}Type::get(Type)
Bug found with AFL fuzz.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@236073 91177308-0d34-0410-b5e6-96231b3b80d8
2015-04-29 01:27:01 +00:00
Filipe Cabecinhas
7acbf56112 Relax an assert when there's a type mismatch in forward references
Summary:
We don't seem to need to assert here, since this function's callers expect
to get a nullptr on error. This way we don't assert on user input.

Bug found with AFL fuzz.

Reviewers: rafael

Subscribers: llvm-commits

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

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@236027 91177308-0d34-0410-b5e6-96231b3b80d8
2015-04-28 20:18:47 +00:00
David Blaikie
974d5d32c8 [opaque pointer type] Encode the pointee type in the bitcode for 'cmpxchg'
As a space optimization, this instruction would just encode the pointer
type of the first operand and use the knowledge that the second and
third operands would be of the pointee type of the first. When typed
pointers go away, this assumption will no longer be available - so
encode the type of the second operand explicitly and rely on that for
the third.

Test case added to demonstrate the backwards compatibility concern,
which only comes up when the definition of the second operand comes
after the use (hence the weird basic block sequence) - at which point
the type needs to be explicitly encoded in the bitcode and the record
length changes to accommodate this.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@235966 91177308-0d34-0410-b5e6-96231b3b80d8
2015-04-28 04:30:29 +00:00
David Blaikie
c5b1f0a49d [opaque pointer type] bitcode: add explicit callee type to invoke instructions
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@235735 91177308-0d34-0410-b5e6-96231b3b80d8
2015-04-24 18:06:06 +00:00
Filipe Cabecinhas
45a69610a7 [BitcodeReader] Fix asserts when we read a non-vector type for insert/extract/shuffle
Added some additional checking for vector types + tests.

Bug found with AFL fuzz.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@235710 91177308-0d34-0410-b5e6-96231b3b80d8
2015-04-24 11:30:15 +00:00
Filipe Cabecinhas
0236022390 Be more strict about the operand for the array type in BitcodeReader
Summary: Bug found with AFL fuzz.

Reviewers: rafael

Subscribers: llvm-commits

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

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@235596 91177308-0d34-0410-b5e6-96231b3b80d8
2015-04-23 13:38:21 +00:00
Filipe Cabecinhas
81f9bd3e19 Verify sizes when trying to read a BitcodeAbbrevOp
Summary:
Make sure the abbrev operands are valid and that we can read/skip them
afterwards.

Bug found with AFL fuzz.

Reviewers: rafael

Subscribers: llvm-commits

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

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@235595 91177308-0d34-0410-b5e6-96231b3b80d8
2015-04-23 13:25:35 +00:00
Filipe Cabecinhas
e16cac587a Have more strict type checks when creating BinOp nodes in BitcodeReader
Summary: Bug found with AFL.

Reviewers: rafael, bkramer

Subscribers: llvm-commits

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

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@235489 91177308-0d34-0410-b5e6-96231b3b80d8
2015-04-22 09:06:21 +00:00
David Blaikie
5023f151a7 [opaque pointer type] Explicit pointee type for call instruction
Use an extra bit in the CCInfo to flag the newer version of the
instructiont hat includes the type explicitly.

Tested the newer error cases I added, but didn't add tests for the finer
granularity improvements to existing error paths.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@235160 91177308-0d34-0410-b5e6-96231b3b80d8
2015-04-17 06:40:14 +00:00
David Blaikie
32b845d223 [opaque pointer type] Add textual IR support for explicit type parameter to the call instruction
See r230786 and r230794 for similar changes to gep and load
respectively.

Call is a bit different because it often doesn't have a single explicit
type - usually the type is deduced from the arguments, and just the
return type is explicit. In those cases there's no need to change the
IR.

When that's not the case, the IR usually contains the pointer type of
the first operand - but since typed pointers are going away, that
representation is insufficient so I'm just stripping the "pointerness"
of the explicit type away.

This does make the IR a bit weird - it /sort of/ reads like the type of
the first operand: "call void () %x(" but %x is actually of type "void
()*" and will eventually be just of type "ptr". But this seems not too
bad and I don't think it would benefit from repeating the type
("void (), void () * %x(" and then eventually "void (), ptr %x(") as has
been done with gep and load.

This also has a side benefit: since the explicit type is no longer a
pointer, there's no ambiguity between an explicit type and a function
that returns a function pointer. Previously this case needed an explicit
type (eg: a function returning a void() function was written as
"call void () () * @x(" rather than "call void () * @x(" because of the
ambiguity between a function returning a pointer to a void() function
and a function returning void).

No ambiguity means even function pointer return types can just be
written alone, without writing the whole function's type.

This leaves /only/ the varargs case where the explicit type is required.

Given the special type syntax in call instructions, the regex-fu used
for migration was a bit more involved in its own unique way (as every
one of these is) so here it is. Use it in conjunction with the apply.sh
script and associated find/xargs commands I've provided in rr230786 to
migrate your out of tree tests. Do let me know if any of this doesn't
cover your cases & we can iterate on a more general script/regexes to
help others with out of tree tests.

About 9 test cases couldn't be automatically migrated - half of those
were functions returning function pointers, where I just had to manually
delete the function argument types now that we didn't need an explicit
function type there. The other half were typedefs of function types used
in calls - just had to manually drop the * from those.

import fileinput
import sys
import re

pat = re.compile(r'((?:=|:|^|\s)call\s(?:[^@]*?))(\s*$|\s*(?:(?:\[\[[a-zA-Z0-9_]+\]\]|[@%](?:(")?[\\\?@a-zA-Z0-9_.]*?(?(3)"|)|{{.*}}))(?:\(|$)|undef|inttoptr|bitcast|null|asm).*$)')
addrspace_end = re.compile(r"addrspace\(\d+\)\s*\*$")
func_end = re.compile("(?:void.*|\)\s*)\*$")

def conv(match, line):
  if not match or re.search(addrspace_end, match.group(1)) or not re.search(func_end, match.group(1)):
    return line
  return line[:match.start()] + match.group(1)[:match.group(1).rfind('*')].rstrip() + match.group(2) + line[match.end():]

for line in sys.stdin:
  sys.stdout.write(conv(re.search(pat, line), line))

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@235145 91177308-0d34-0410-b5e6-96231b3b80d8
2015-04-16 23:24:18 +00:00
Sanjoy Das
5ff5907996 [IR] Introduce a dereferenceable_or_null(N) attribute.
Summary:
If a pointer is marked as dereferenceable_or_null(N), LLVM assumes it
is either `null` or `dereferenceable(N)` or both.  This change only
introduces the attribute and adds a token test case for the `llvm-as`
/ `llvm-dis`.  It does not hook up other parts of the optimizer to
actually exploit the attribute -- those changes will come later.

For pointers in address space 0, `dereferenceable(N)` is now exactly
equivalent to `dereferenceable_or_null(N)` && `nonnull`.  For other
address spaces, `dereferenceable(N)` is potentially weaker than
`dereferenceable_or_null(N)` && `nonnull` (since we could have a null
`dereferenceable(N)` pointer).

The motivating case for this change is Java (and other managed
languages), where pointers are either `null` or dereferenceable up to
some usually known-at-compile-time constant offset.

Reviewers: rafael, hfinkel

Reviewed By: hfinkel

Subscribers: nicholas, llvm-commits

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

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@235132 91177308-0d34-0410-b5e6-96231b3b80d8
2015-04-16 20:29:50 +00:00
Filipe Cabecinhas
f72ee4c275 Revert "Verify sizes when trying to read a VBR"
This reverts r234984 since it seems to break some bots (most of them
seemed arm*-selfhost).

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@234998 91177308-0d34-0410-b5e6-96231b3b80d8
2015-04-15 11:10:17 +00:00
Filipe Cabecinhas
4c0055402f Verify sizes when trying to read a VBR
Also added an assert to ReadVBR64.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@234984 91177308-0d34-0410-b5e6-96231b3b80d8
2015-04-15 08:48:08 +00:00
Filipe Cabecinhas
9a1030a4d6 Error out of ParseBitcodeInto(Module*) if we haven't read a Module
Summary:
Without this check the following case failed:

Skip a SubBlock which is not a MODULE_BLOCK_ID nor a BLOCKINFO_BLOCK_ID
Got to end of file

TheModule would still be == nullptr, and we would subsequentially fail
when materializing the Module (assert at the start of
BitcodeReader::MaterializeModule).

Bug found with AFL.

Reviewers: dexonsmith, rafael

Subscribers: llvm-commits

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

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@234887 91177308-0d34-0410-b5e6-96231b3b80d8
2015-04-14 14:07:15 +00:00
David Blaikie
712d00bc64 Add testing for mismatched explicit type on a gep operator when loading from bitcode
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@232427 91177308-0d34-0410-b5e6-96231b3b80d8
2015-03-16 22:03:50 +00:00
David Blaikie
2a83bf6228 Add testing for mismatched explicit type on a load instruction when loading from bitcode
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@232424 91177308-0d34-0410-b5e6-96231b3b80d8
2015-03-16 21:48:46 +00:00
David Blaikie
f1d4614418 Test bitcode parsing error-handling for incorrect explicit type
(turns out I had regressed this when sinking handling of this type down
into GetElementPtrInst::Create - since that asserted before the error
handling was performed)

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@232420 91177308-0d34-0410-b5e6-96231b3b80d8
2015-03-16 21:35:48 +00:00
David Blaikie
5a70dd1d82 [opaque pointer type] Add textual IR support for explicit type parameter to gep operator
Similar to gep (r230786) and load (r230794) changes.

Similar migration script can be used to update test cases, which
successfully migrated all of LLVM and Polly, but about 4 test cases
needed manually changes in Clang.

(this script will read the contents of stdin and massage it into stdout
- wrap it in the 'apply.sh' script shown in previous commits + xargs to
apply it over a large set of test cases)

import fileinput
import sys
import re

rep = re.compile(r"(getelementptr(?:\s+inbounds)?\s*\()((<\d*\s+x\s+)?([^@]*?)(|\s*addrspace\(\d+\))\s*\*(?(3)>)\s*)(?=$|%|@|null|undef|blockaddress|getelementptr|addrspacecast|bitcast|inttoptr|zeroinitializer|<|\[\[[a-zA-Z]|\{\{)", re.MULTILINE | re.DOTALL)

def conv(match):
  line = match.group(1)
  line += match.group(4)
  line += ", "
  line += match.group(2)
  return line

line = sys.stdin.read()
off = 0
for match in re.finditer(rep, line):
  sys.stdout.write(line[off:match.start()])
  sys.stdout.write(conv(match))
  off = match.end()
sys.stdout.write(line[off:])

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@232184 91177308-0d34-0410-b5e6-96231b3b80d8
2015-03-13 18:20:45 +00:00
Mehdi Amini
c94da20917 Make DataLayout Non-Optional in the Module
Summary:
DataLayout keeps the string used for its creation.

As a side effect it is no longer needed in the Module.
This is "almost" NFC, the string is no longer
canonicalized, you can't rely on two "equals" DataLayout
having the same string returned by getStringRepresentation().

Get rid of DataLayoutPass: the DataLayout is in the Module

The DataLayout is "per-module", let's enforce this by not
duplicating it more than necessary.
One more step toward non-optionality of the DataLayout in the
module.

Make DataLayout Non-Optional in the Module

Module->getDataLayout() will never returns nullptr anymore.

Reviewers: echristo

Subscribers: resistor, llvm-commits, jholewinski

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

From: Mehdi Amini <mehdi.amini@apple.com>

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@231270 91177308-0d34-0410-b5e6-96231b3b80d8
2015-03-04 18:43:29 +00:00
David Blaikie
7c9c6ed761 [opaque pointer type] Add textual IR support for explicit type parameter to load instruction
Essentially the same as the GEP change in r230786.

A similar migration script can be used to update test cases, though a few more
test case improvements/changes were required this time around: (r229269-r229278)

import fileinput
import sys
import re

pat = re.compile(r"((?:=|:|^)\s*load (?:atomic )?(?:volatile )?(.*?))(| addrspace\(\d+\) *)\*($| *(?:%|@|null|undef|blockaddress|getelementptr|addrspacecast|bitcast|inttoptr|\[\[[a-zA-Z]|\{\{).*$)")

for line in sys.stdin:
  sys.stdout.write(re.sub(pat, r"\1, \2\3*\4", line))

Reviewers: rafael, dexonsmith, grosser

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

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@230794 91177308-0d34-0410-b5e6-96231b3b80d8
2015-02-27 21:17:42 +00:00
David Blaikie
198d8baafb [opaque pointer type] Add textual IR support for explicit type parameter to getelementptr instruction
One of several parallel first steps to remove the target type of pointers,
replacing them with a single opaque pointer type.

This adds an explicit type parameter to the gep instruction so that when the
first parameter becomes an opaque pointer type, the type to gep through is
still available to the instructions.

* This doesn't modify gep operators, only instructions (operators will be
  handled separately)

* Textual IR changes only. Bitcode (including upgrade) and changing the
  in-memory representation will be in separate changes.

* geps of vectors are transformed as:
    getelementptr <4 x float*> %x, ...
  ->getelementptr float, <4 x float*> %x, ...
  Then, once the opaque pointer type is introduced, this will ultimately look
  like:
    getelementptr float, <4 x ptr> %x
  with the unambiguous interpretation that it is a vector of pointers to float.

* address spaces remain on the pointer, not the type:
    getelementptr float addrspace(1)* %x
  ->getelementptr float, float addrspace(1)* %x
  Then, eventually:
    getelementptr float, ptr addrspace(1) %x

Importantly, the massive amount of test case churn has been automated by
same crappy python code. I had to manually update a few test cases that
wouldn't fit the script's model (r228970,r229196,r229197,r229198). The
python script just massages stdin and writes the result to stdout, I
then wrapped that in a shell script to handle replacing files, then
using the usual find+xargs to migrate all the files.

update.py:
import fileinput
import sys
import re

ibrep = re.compile(r"(^.*?[^%\w]getelementptr inbounds )(((?:<\d* x )?)(.*?)(| addrspace\(\d\)) *\*(|>)(?:$| *(?:%|@|null|undef|blockaddress|getelementptr|addrspacecast|bitcast|inttoptr|\[\[[a-zA-Z]|\{\{).*$))")
normrep = re.compile(       r"(^.*?[^%\w]getelementptr )(((?:<\d* x )?)(.*?)(| addrspace\(\d\)) *\*(|>)(?:$| *(?:%|@|null|undef|blockaddress|getelementptr|addrspacecast|bitcast|inttoptr|\[\[[a-zA-Z]|\{\{).*$))")

def conv(match, line):
  if not match:
    return line
  line = match.groups()[0]
  if len(match.groups()[5]) == 0:
    line += match.groups()[2]
  line += match.groups()[3]
  line += ", "
  line += match.groups()[1]
  line += "\n"
  return line

for line in sys.stdin:
  if line.find("getelementptr ") == line.find("getelementptr inbounds"):
    if line.find("getelementptr inbounds") != line.find("getelementptr inbounds ("):
      line = conv(re.match(ibrep, line), line)
  elif line.find("getelementptr ") != line.find("getelementptr ("):
    line = conv(re.match(normrep, line), line)
  sys.stdout.write(line)

apply.sh:
for name in "$@"
do
  python3 `dirname "$0"`/update.py < "$name" > "$name.tmp" && mv "$name.tmp" "$name"
  rm -f "$name.tmp"
done

The actual commands:
From llvm/src:
find test/ -name *.ll | xargs ./apply.sh
From llvm/src/tools/clang:
find test/ -name *.mm -o -name *.m -o -name *.cpp -o -name *.c | xargs -I '{}' ../../apply.sh "{}"
From llvm/src/tools/polly:
find test/ -name *.ll | xargs ./apply.sh

After that, check-all (with llvm, clang, clang-tools-extra, lld,
compiler-rt, and polly all checked out).

The extra 'rm' in the apply.sh script is due to a few files in clang's test
suite using interesting unicode stuff that my python script was throwing
exceptions on. None of those files needed to be migrated, so it seemed
sufficient to ignore those cases.

Reviewers: rafael, dexonsmith, grosser

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

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@230786 91177308-0d34-0410-b5e6-96231b3b80d8
2015-02-27 19:29:02 +00:00
Duncan P. N. Exon Smith
aaff953db4 llvm-dis: Stop crashing when dropping debug info
Since r199356, we've printed a warning when dropping debug info.
r225562 started crashing on that, since it registered a diagnostic
handler that only expected errors.  This fixes the handler to expect
other severities.  As a side effect, it now prints "error: " at the
start of error messages, similar to `llvm-as`.

There was a testcase for r199356, but it only really checked the
assembler.  Move `test/Bitcode/drop-debug-info.ll` to `test/Assembler`,
and introduce `test/Bitcode/drop-debug-info.3.5.ll` (and companion
`.bc`) to test the bitcode reader.

Note: tools/gold/gold-plugin.cpp has an equivalent bug, but I'm not sure
what the best fix is there.  I'll file a PR.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@230416 91177308-0d34-0410-b5e6-96231b3b80d8
2015-02-25 01:10:03 +00:00
David Blaikie
6606ad944b [opaque pointer type] Bitcode support for explicit type parameter on GEP.
Like r230414, add bitcode support including backwards compatibility, for
an explicit type parameter to GEP.

At the suggestion of Duncan I tried coalescing the two older bitcodes into a
single new bitcode, though I did hit a wrinkle: I couldn't figure out how to
create an explicit abbreviation for a record with a variable number of
arguments (the indicies to the gep). This means the discriminator between
inbounds and non-inbounds gep is a full variable-length field I believe? Is my
understanding correct? Is there a way to create such an abbreviation? Should I
just use two bitcodes as before?

Reviewers: dexonsmith

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

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@230415 91177308-0d34-0410-b5e6-96231b3b80d8
2015-02-25 01:08:52 +00:00
JF Bastien
8c253f7e88 Use common parse routine to read alignment values from bitcode
While fuzzing LLVM bitcode files, I discovered that (1) the bitcode reader doesn't check that alignments are no larger than 2**29; (2) downstream code doesn't check the range; and (3) for values out of range, corresponding large memory requests (based on alignment size) will fail. This code fixes the bitcode reader to check for valid alignments, fixing this problem.

This CL fixes alignment value on global variables, functions, and instructions: alloca, load, load atomic, store, store atomic.

Patch by Karl Schimpf (kschimpf@google.com).

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@230180 91177308-0d34-0410-b5e6-96231b3b80d8
2015-02-22 19:32:03 +00:00