RPCS3/llvm-mirror
1
0
Fork 0
mirror of https://github.com/RPCS3/llvm-mirror.git synced 2024-10-23 04:52:54 +02:00
Code Issues Projects Releases Wiki Activity
121,923 Commits 4 Branches 5 Tags 704 MiB
f5eccb0155
Commit Graph

7 Commits

Author SHA1 Message Date
Reid Kleckner
5caec8e071 [IR] Print the label operands of a catchpad like an invoke 
The rest of the EH pads are fine, since they have at most one label and
take fewer operands for the personality.

Old catchpad vs. new:
  %5 = catchpad [i8* bitcast (i32 ()* @"\01?filt$0@0@main@@" to i8*)] to label %__except.ret.10 unwind label %catchendblock.9
-----
  %5 = catchpad [i8* bitcast (i32 ()* @"\01?filt$0@0@main@@" to i8*)]
          to label %__except.ret.10 unwind label %catchendblock.9

llvm-svn: 247433
 2015-09-11 17:27:52 +00:00
David Blaikie
65b92c4f37 [opaque pointer type] Add textual IR support for explicit type parameter for global aliases 
update.py:
import fileinput
import sys
import re

alias_match_prefix = r"(.*(?:=|:|^)\s*(?:external |)(?:(?:private|internal|linkonce|linkonce_odr|weak|weak_odr|common|appending|extern_weak|available_externally) )?(?:default |hidden |protected )?(?:dllimport |dllexport )?(?:unnamed_addr |)(?:thread_local(?:\([a-z]*\))? )?alias"
plain = re.compile(alias_match_prefix + r" (.*?))(| addrspace\(\d+\) *)\*($| *(?:%|@|null|undef|blockaddress|addrspacecast|\[\[[a-zA-Z]|\{\{).*$)")
cast  = re.compile(alias_match_prefix + r") ((?:bitcast|inttoptr|addrspacecast)\s*\(.* to (.*?)(| addrspace\(\d+\) *)\*\)\s*(?:;.*)?$)")
gep   = re.compile(alias_match_prefix + r") ((?:getelementptr)\s*(?:inbounds)?\s*\((?P<type>.*), (?P=type)(?:\s*addrspace\(\d+\)\s*)?\* .*\)\s*(?:;.*)?$)")

def conv(line):
  m = re.match(cast, line)
  if m:
    return m.group(1) + " " + m.group(3) + ", " + m.group(2)
  m = re.match(gep, line)
  if m:
    return m.group(1) + " " + m.group(3) + ", " + m.group(2)
  m = re.match(plain, line)
  if m:
    return m.group(1) + ", " + m.group(2) + m.group(3) + "*" + m.group(4) + "\n"
  return line

for line in sys.stdin:
  sys.stdout.write(conv(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

llvm-svn: 247378
 2015-09-11 03:22:04 +00:00
Vedant Kumar
dd7057a64c [Bitcode] Add compatibility tests for new instructions 
Adds basic compatibility tests for the following instructions:

  catchpad, catchendpad, cleanuppad, cleanupendpad, terminatepad,
  cleanupret, catchret

llvm-svn: 247087
 2015-09-08 22:33:23 +00:00
Vedant Kumar
9bbaaad734 [test] Testing write access to llvm 
llvm-svn: 245074
 2015-08-14 17:42:50 +00:00
David Majnemer
10f2d9234b [IR] Add token types 
This introduces the basic functionality to support "token types".
The motivation stems from the need to perform operations on a Value
whose provenance cannot be obscured.

There are several applications for such a type but my immediate
motivation stems from WinEH.  Our personality routine enforces a
single-entry - single-exit regime for cleanups.  After several rounds of
optimizations, we may be left with a terminator whose "cleanup-entry
block" is not entirely clear because control flow has merged two
cleanups together.  We have experimented with using labels as operands
inside of instructions which are not terminators to indicate where we
came from but found that LLVM does not expect such exotic uses of
BasicBlocks.

Instead, we can use this new type to clearly associate the "entry point"
and "exit point" of our cleanup.  This is done by having the cleanuppad
yield a Token and consuming it at the cleanupret.
The token type makes it impossible to obscure or otherwise hide the
Value, making it trivial to track the relationship between the two
points.

What is the burden to the optimizer?  Well, it turns out we have already
paid down this cost by accepting that there are certain calls that we
are not permitted to duplicate, optimizations have to watch out for
such instructions anyway.  There are additional places in the optimizer
that we will probably have to update but early examination has given me
the impression that this will not be heroic.

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

llvm-svn: 245029
 2015-08-14 05:09:07 +00:00
Igor Laevsky
15b7b9c050 Emit argmemonly attribute for intrinsics. 
Differential Revision: http://reviews.llvm.org/D11352

llvm-svn: 244920
 2015-08-13 17:40:04 +00:00
Duncan P. N. Exon Smith
b87fbd089e IR: Add a broad bitcode compatibility test 
Successive versions of LLVM should retain the ability to parse bitcode
generated by old releases of the compiler.  This adds a bitcode format
compatibility test, which is intended to provide good (albeit not
entirely exhaustive) coverage of the current LangRef.

This also includes compatibility tests for LLVM 3.6.  After every 3.X.0
release, the compatibility.ll file from the 3.X branch should be copied
to compatibility-3.X.ll on trunk, and the 3.X.0 release used to generate
a corresponding bitcode file.

Patch by Vedant Kumar!

llvm-svn: 243779
 2015-07-31 20:44:32 +00:00