| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
| |
This change now applies ppcg's GPU mapping on our initial schedule. For this
to work, we need to also initialize the set of all names (isl_ids) used in
the scop as well as the program context.
llvm-svn: 275396
|
| |
|
|
| |
llvm-svn: 275395
|
| |
|
|
| |
llvm-svn: 275394
|
| |
|
|
|
|
|
|
|
|
| |
provide them
Android API <= 16 header do not have these symbols defined, but the kernel does support the
relevant calls. And in general, since these calls are on a best-effort basis, it won't hurt even
if we try to run in on a really ancient kernel.
llvm-svn: 275393
|
| |
|
|
|
|
| |
optimization pattern"
llvm-svn: 275392
|
| |
|
|
| |
llvm-svn: 275391
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
To do so we copy the necessary information to compute an initial schedule from
polly::Scop to ppcg's scop. Most of the necessary information is directly
available and only needs to be passed on to ppcg, with the exception of 'tagged'
access relations, access relations that additionally carry information about
which memory access an access relation originates from.
We could possibly perform the construction of tagged accesses as part of
ScopInfo, but as this format is currently specific to ppcg we do not do this
yet, but keep this functionality local to our GPU code generation.
After the scop has been initialized, we compute data dependences and ask ppcg to
compute an initial schedule. Some of this functionality is already available in
polly::DependenceInfo and polly::ScheduleOptimizer, but to keep differences
to ppcg small we use ppcg's functionality here. We may later investiage if
a closer integration of these tools makes sense.
llvm-svn: 275390
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
At this stage, we do not yet modify the IR but just generate a default
initialized ppcg_scop and gpu_prog and free both immediately. Both will later be
filled with data from the polly::Scop and are needed to use PPCG for GPU
schedule generation. This commit does not yet perform any GPU code generation,
but ensures that the basic infrastructure has been put in place.
We also add a simple test case to ensure the new code is run and use this
opportunity to verify that GPU_CODEGEN tests are only run if GPU code generation
has been enabled in cmake.
llvm-svn: 275389
|
| |
|
|
|
|
|
|
|
|
|
| |
clang-rename needs at least to have a minimum documentation to provide a
small introduction for new users
Patch by Kirill Bobyrev!
Differential Revision: http://reviews.llvm.org/D22129
llvm-svn: 275388
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch does the following:
* enforces proper formatting for few files (i.e. deals with 80 linewidth violations and few other things)
* ensures '\n' chars are passed to the output streams instead of "\n" strings
* fixes a bug caused by calling cl::PrintHelpMessage(), which occasionally calls exit(0), so that exit(1) (which is right after cl::PrintHelpMessage line) becomes dead code
Patch by Kirill Bobyrev!
Differential Revision: http://reviews.llvm.org/D22091
llvm-svn: 275387
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
The judgement that checks whether the fully-qualified name has scoped qualifiers
prefix is incorrect. Should always check whether the first matched postion is the
beginning position.
Reviewers: bkramer
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D22343
llvm-svn: 275386
|
| |
|
|
| |
llvm-svn: 275385
|
| |
|
|
|
|
| |
add "__" prefix
llvm-svn: 275384
|
| |
|
|
| |
llvm-svn: 275383
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
constant hoisting. It not only takes into account the number of uses and the
cost of expressions in which constants appear, but now also the resulting
integer range of the offsets. Thus, the algorithm maximizes the number of uses
within an integer range that will enable more efficient code generation. On
ARM, for example, this will enable code size optimisations because less
negative offsets will be created. Negative offsets/immediates are not supported
by Thumb1 thus preventing more compact instruction encoding.
Differential Revision: http://reviews.llvm.org/D21183
llvm-svn: 275382
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
* Previously -break-enable mistakenly set BP's enabled flag to false.
* These commands print fake =breakpoint-modified messages, what's not
needed anymore because that events are come in normal way.
* Add tests for -break-enable/-break-disable commands
Initial patch from xuefangliang@hotmail.com. The test case was improved by me.
Differential Revision: http://reviews.llvm.org/D21757
llvm-svn: 275381
|
| |
|
|
|
|
|
|
| |
We were able to fold masked loads with an all-ones mask to a normal
load. However, we couldn't turn a masked load with a mask with mixed
ones and undefs into a normal load.
llvm-svn: 275380
|
| |
|
|
|
|
|
| |
We can always pick the passthru value if the mask is undef: we are
permitted to treat the mask as-if it were filled with zeros.
llvm-svn: 275379
|
| |
|
|
|
|
| |
instructions instead of creating CodeGenOnly instructions.
llvm-svn: 275378
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Summary: Fix the build to use hasFlag instead of hasArg for checking some flags.
Reviewers: echristo
Subscribers: mehdi_amini, cfe-commits
Differential Revision: http://reviews.llvm.org/D22338
llvm-svn: 275377
|
| |
|
|
|
|
|
| |
Apparently someone miscounted the number of zeros in the immediate.
Fixes https://llvm.org/bugs/show_bug.cgi?id=28544 .
llvm-svn: 275376
|
| |
|
|
|
|
| |
Use the replacement pass to update the tests, and delete old names.
llvm-svn: 275375
|
| |
|
|
|
|
|
|
| |
ELF spec says that alignment of 0 is equivalent to 1.
Previously, we arbitrary set to 0 or 1, but always setting to 1
makes our program simpler.
llvm-svn: 275374
|
| |
|
|
|
|
|
|
| |
r275301 made .got section be aligned on Target->GotEntrySize,
so GotEntrySize must have been initialized. We didn't initialize
it for AMDGPU.
llvm-svn: 275373
|
| |
|
|
|
|
| |
Mesa removed this path, so nothing is using these anymore.
llvm-svn: 275372
|
| |
|
|
| |
llvm-svn: 275371
|
| |
|
|
|
|
|
|
|
|
| |
It wasn't actually running the pass, and since it is
missing the llvm prefix, the eh intrinsic was not
really an IntrinsicInst.
Also add missing test for lifetime markers.
llvm-svn: 275370
|
| |
|
|
| |
llvm-svn: 275369
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Depends on D21982 which implements the in-memory logging implementation of the
XRay runtime. These additional changes also depends on D20352 which adds the
bulk of XRay flags/dependencies when using the `-fxray-instrument` flag from
Clang.
Reviewers: echristo, rnk, aaron.ballman
Subscribers: mehdi_amini, cfe-commits
Differential Revision: http://reviews.llvm.org/D21983
llvm-svn: 275368
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
In this patch we implement the following parts of XRay:
- Supporting a function attribute named 'function-instrument' which currently only supports 'xray-always'. We should be able to use this attribute for other instrumentation approaches.
- Supporting a function attribute named 'xray-instruction-threshold' used to determine whether a function is instrumented with a minimum number of instructions (IR instruction counts).
- X86-specific nop sleds as described in the white paper.
- A machine function pass that adds the different instrumentation marker instructions at a very late stage.
- A way of identifying which return opcode is considered "normal" for each architecture.
There are some caveats here:
1) We don't handle PATCHABLE_RET in platforms other than x86_64 yet -- this means if IR used PATCHABLE_RET directly instead of a normal ret, instruction lowering for that platform might do the wrong thing. We think this should be handled at instruction selection time to by default be unpacked for platforms where XRay is not availble yet.
2) The generated section for X86 is different from what is described from the white paper for the sole reason that LLVM allows us to do this neatly. We're taking the opportunity to deviate from the white paper from this perspective to allow us to get richer information from the runtime library.
Reviewers: sanjoy, eugenis, kcc, pcc, echristo, rnk
Subscribers: niravd, majnemer, atrick, rnk, emaste, bmakam, mcrosier, mehdi_amini, llvm-commits
Differential Revision: http://reviews.llvm.org/D19904
llvm-svn: 275367
|
| |
|
|
|
|
| |
Thanks to Eli for the suggestion!
llvm-svn: 275366
|
| |
|
|
|
|
|
|
| |
This patch is to implement sema and parsing for 'target parallel for simd' pragma.
Differential Revision: http://reviews.llvm.org/D22096
llvm-svn: 275365
|
| |
|
|
| |
llvm-svn: 275364
|
| |
|
|
|
|
|
|
|
|
|
| |
values are constant.
This now should also work with the interprocedural variant of the pass.
Slightly easier now that the yak is shaved.
Differential Revision: http://reviews.llvm.org/D22329
llvm-svn: 275363
|
| |
|
|
| |
llvm-svn: 275362
|
| |
|
|
| |
llvm-svn: 275361
|
| |
|
|
|
|
| |
http://reviews.llvm.org/D22315
llvm-svn: 275360
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
In Scalarizer::gather we see if we already have a scattered form of Op,
and in that case use the new form.
In the particular case of PR28108, the found ValueVector SV has size 2,
where the first Value is nullptr, and the second is indeed a proper Value.
The nullptr then caused an assert to blow when we tried to do
cast<Instruction>(SV[I]).
With this patch we check SV[I] before doing the cast, and if it's nullptr
we just skip over it.
I don't know the Scalarizer well enough to know if this is the best fix
or if something should be done else where to prevent the nullptr from
being in the ValueVector at all, but at least this avoids the crash
and looking at the test case output it looks reasonable.
Reviewers: hfinkel, frasercrmck, wala, mehdi_amini
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D21518
llvm-svn: 275359
|
| |
|
|
|
|
| |
local function when IPRA is enabled."
llvm-svn: 275358
|
| |
|
|
| |
llvm-svn: 275357
|
| |
|
|
| |
llvm-svn: 275356
|
| |
|
|
|
|
|
| |
While some code paths in MIRParserImpl::parse() already returned nullptr
in case of error one of the important ones did not.
llvm-svn: 275355
|
| |
|
|
|
|
|
|
|
|
| |
This adds Clang-specific DWARF constants for nullability and ObjC
class properties that are already generated by clang. This patch adds
dwarfdump support and a more comprehensive testcase.
<rdar://problem/27335745>
llvm-svn: 275354
|
| |
|
|
|
|
| |
Should fix the bots broken by r275316.
llvm-svn: 275353
|
| |
|
|
|
|
|
|
|
| |
We can constant fold a masked load if the operands are appropriately
constant.
Differential Revision: http://reviews.llvm.org/D22324
llvm-svn: 275352
|
| |
|
|
| |
llvm-svn: 275351
|
| |
|
|
|
|
|
|
|
|
| |
'if' and 'switch':
if (stmt; condition) { ... }
Patch by Anton Bikineev! Some minor formatting and comment tweets by me.
llvm-svn: 275350
|
| |
|
|
|
|
|
|
| |
macro.
This silences a warning about an extra semicolon on gcc.
llvm-svn: 275349
|
| |
|
|
|
|
|
|
|
|
|
|
| |
TargetMachine.cpp
Avoid exposing a cl::opt in a public header and instead promote this
option in the API.
Alternatively, we could land the cl::opt in CommandFlags.h so that
it is available to every tool, but we would still have to find an
option for clang.
llvm-svn: 275348
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
enabled.
IPRA try to optimize caller saved register by propagating register
usage information from callee to caller so it is beneficial to have
caller saved registers compare to callee saved registers when IPRA
is enabled. Please find more detailed explanation here
https://groups.google.com/d/msg/llvm-dev/XRzGhJ9wtZg/tjAJqb0eEgAJ.
This change makes local function do not have any callee preserved
register when IPRA is enabled. A simple test case is also added to
verify this change.
Patch by Vivek Pandya <vivekvpandya@gmail.com>
Differential Revision: http://reviews.llvm.org/D21561
llvm-svn: 275347
|