Commit Graph

590 Commits

Author SHA1 Message Date
Michael Kruse 978ba61536 Introduce llvm.loop.parallel_accesses and llvm.access.group metadata.
The current llvm.mem.parallel_loop_access metadata has a problem in that
it uses LoopIDs. LoopID unfortunately is not loop identifier. It is
neither unique (there's even a regression test assigning the some LoopID
to multiple loops; can otherwise happen if passes such as LoopVersioning
make copies of entire loops) nor persistent (every time a property is
removed/added from a LoopID's MDNode, it will also receive a new LoopID;
this happens e.g. when calling Loop::setLoopAlreadyUnrolled()).
Since most loop transformation passes change the loop attributes (even
if it just to mark that a loop should not be processed again as
llvm.loop.isvectorized does, for the versioned and unversioned loop),
the parallel access information is lost for any subsequent pass.

This patch unlinks LoopIDs and parallel accesses.
llvm.mem.parallel_loop_access metadata on instruction is replaced by
llvm.access.group metadata. llvm.access.group points to a distinct
MDNode with no operands (avoiding the problem to ever need to add/remove
operands), called "access group". Alternatively, it can point to a list
of access groups. The LoopID then has an attribute
llvm.loop.parallel_accesses with all the access groups that are parallel
(no dependencies carries by this loop).

This intentionally avoid any kind of "ID". Loops that are clones/have
their attributes modifies retain the llvm.loop.parallel_accesses
attribute. Access instructions that a cloned point to the same access
group. It is not necessary for each access to have it's own "ID" MDNode,
but those memory access instructions with the same behavior can be
grouped together.

The behavior of llvm.mem.parallel_loop_access is not changed by this
patch, but should be considered deprecated.

Differential Revision: https://reviews.llvm.org/D52116

llvm-svn: 349725
2018-12-20 04:58:07 +00:00
Michael Kruse 82dd71ef6d [docs] Use correct ending quotes.
llvm-svn: 348947
2018-12-12 17:59:01 +00:00
Michael Kruse 7244852557 [Unroll/UnrollAndJam/Vectorizer/Distribute] Add followup loop attributes.
When multiple loop transformation are defined in a loop's metadata, their order of execution is defined by the order of their respective passes in the pass pipeline. For instance, e.g.

    #pragma clang loop unroll_and_jam(enable)
    #pragma clang loop distribute(enable)

is the same as

    #pragma clang loop distribute(enable)
    #pragma clang loop unroll_and_jam(enable)

and will try to loop-distribute before Unroll-And-Jam because the LoopDistribute pass is scheduled after UnrollAndJam pass. UnrollAndJamPass only supports one inner loop, i.e. it will necessarily fail after loop distribution. It is not possible to specify another execution order. Also,t the order of passes in the pipeline is subject to change between versions of LLVM, optimization options and which pass manager is used.

This patch adds 'followup' attributes to various loop transformation passes. These attributes define which attributes the resulting loop of a transformation should have. For instance,

    !0 = !{!0, !1, !2}
    !1 = !{!"llvm.loop.unroll_and_jam.enable"}
    !2 = !{!"llvm.loop.unroll_and_jam.followup_inner", !3}
    !3 = !{!"llvm.loop.distribute.enable"}

defines a loop ID (!0) to be unrolled-and-jammed (!1) and then the attribute !3 to be added to the jammed inner loop, which contains the instruction to distribute the inner loop.

Currently, in both pass managers, pass execution is in a fixed order and UnrollAndJamPass will not execute again after LoopDistribute. We hope to fix this in the future by allowing pass managers to run passes until a fixpoint is reached, use Polly to perform these transformations, or add a loop transformation pass which takes the order issue into account.

For mandatory/forced transformations (e.g. by having been declared by #pragma omp simd), the user must be notified when a transformation could not be performed. It is not possible that the responsible pass emits such a warning because the transformation might be 'hidden' in a followup attribute when it is executed, or it is not present in the pipeline at all. For this reason, this patche introduces a WarnMissedTransformations pass, to warn about orphaned transformations.

Since this changes the user-visible diagnostic message when a transformation is applied, two test cases in the clang repository need to be updated.

To ensure that no other transformation is executed before the intended one, the attribute `llvm.loop.disable_nonforced` can be added which should disable transformation heuristics before the intended transformation is applied. E.g. it would be surprising if a loop is distributed before a #pragma unroll_and_jam is applied.

With more supported code transformations (loop fusion, interchange, stripmining, offloading, etc.), transformations can be used as building blocks for more complex transformations (e.g. stripmining+stripmining+interchange -> tiling).

Reviewed By: hfinkel, dmgreen

Differential Revision: https://reviews.llvm.org/D49281
Differential Revision: https://reviews.llvm.org/D55288

llvm-svn: 348944
2018-12-12 17:32:52 +00:00
Leonard Chan 118e53fd63 [Intrinsic] Signed Fixed Point Multiplication Intrinsic
Add an intrinsic that takes 2 signed integers with the scale of them provided
as the third argument and performs fixed point multiplication on them.

This is a part of implementing fixed point arithmetic in clang where some of
the more complex operations will be implemented as intrinsics.

Differential Revision: https://reviews.llvm.org/D54719

llvm-svn: 348912
2018-12-12 06:29:14 +00:00
Erik Pilkington bdad92a131 [docs] Add the new Objective-C ARC intrinsics to the LangRef.
These were added in r348441. This mostly just points to the clang documentation
to describe the intended semantics of each intrinsic.

llvm-svn: 348782
2018-12-10 18:19:43 +00:00
Max Kazantsev b9e65cbddf Introduce llvm.experimental.widenable_condition intrinsic
This patch introduces a new instinsic `@llvm.experimental.widenable_condition`
that allows explicit representation for guards. It is an alternative to using
`@llvm.experimental.guard` intrinsic that does not contain implicit control flow.

We keep finding places where `@llvm.experimental.guard` is not supported or
treated too conservatively, and there are 2 reasons to that:

- `@llvm.experimental.guard` has memory write side effect to model implicit control flow,
  and this sometimes confuses passes and analyzes that work with memory;
- Not all passes and analysis are aware of the semantics of guards. These passes treat them
  as regular throwing call and have no idea that the condition of guard may be used to prove
  something. One well-known place which had caused us troubles in the past is explicit loop
  iteration count calculation in SCEV. Another example is new loop unswitching which is not
  aware of guards. Whenever a new pass appears, we potentially have this problem there.

Rather than go and fix all these places (and commit to keep track of them and add support
in future), it seems more reasonable to leverage the existing optimizer's logic as much as possible.
The only significant difference between guards and regular explicit branches is that guard's condition
can be widened. It means that a guard contains (explicitly or implicitly) a `deopt` block successor,
and it is always legal to go there no matter what the guard condition is. The other successor is
a guarded block, and it is only legal to go there if the condition is true.

This patch introduces a new explicit form of guards alternative to `@llvm.experimental.guard`
intrinsic. Now a widenable guard can be represented in the CFG explicitly like this:


    %widenable_condition = call i1 @llvm.experimental.widenable.condition()
    %new_condition = and i1 %cond, %widenable_condition
    br i1 %new_condition, label %guarded, label %deopt

  guarded:
    ; Guarded instructions

  deopt:
    call type @llvm.experimental.deoptimize(<args...>) [ "deopt"(<deopt_args...>) ]

The new intrinsic `@llvm.experimental.widenable.condition` has semantics of an
`undef`, but the intrinsic prevents the optimizer from folding it early. This form
should exploit all optimization boons provided to `br` instuction, and it still can be
widened by replacing the result of `@llvm.experimental.widenable.condition()`
with `and` with any arbitrary boolean value (as long as the branch that is taken when
it is `false` has a deopt and has no side-effects).

For more motivation, please check llvm-dev discussion "[llvm-dev] Giving up using
implicit control flow in guards".

This patch introduces this new intrinsic with respective LangRef changes and a pass
that converts old-style guards (expressed as intrinsics) into the new form.

The naming discussion is still ungoing. Merging this to unblock further items. We can
later change the name of this intrinsic.

Reviewed By: reames, fedor.sergeev, sanjoy
Differential Revision: https://reviews.llvm.org/D51207

llvm-svn: 348593
2018-12-07 14:39:46 +00:00
Zola Bridges cbac3ad122 [clang][slh] add attribute for speculative load hardening
Summary:
Resubmit this with no changes because I think the build was broken
by a different diff.
-----
The prior diff had to be reverted because there were two tests
that failed. I updated the two tests in this diff

clang/test/Misc/pragma-attribute-supported-attributes-list.test
clang/test/SemaCXX/attr-speculative-load-hardening.cpp

----- Summary from Previous Diff (Still Accurate) -----

LLVM IR already has an attribute for speculative_load_hardening. Before
this commit, when a user passed the -mspeculative-load-hardening flag to
Clang, every function would have this attribute added to it. This Clang
attribute will allow users to opt into SLH on a function by function basis.

This can be applied to functions and Objective C methods.

Reviewers: chandlerc, echristo, kristof.beyls, aaron.ballman

Subscribers: llvm-commits

Differential Revision: https://reviews.llvm.org/D54915

llvm-svn: 347701
2018-11-27 19:56:46 +00:00
Zola Bridges 0b35afd79d Revert "[clang][slh] add attribute for speculative load hardening"
until I figure out why the build is failing or timing out

***************************

Summary:
The prior diff had to be reverted because there were two tests
that failed. I updated the two tests in this diff

clang/test/Misc/pragma-attribute-supported-attributes-list.test
clang/test/SemaCXX/attr-speculative-load-hardening.cpp

LLVM IR already has an attribute for speculative_load_hardening. Before
this commit, when a user passed the -mspeculative-load-hardening flag to
Clang, every function would have this attribute added to it. This Clang
attribute will allow users to opt into SLH on a function by function
basis.

This can be applied to functions and Objective C methods.

Reviewers: chandlerc, echristo, kristof.beyls, aaron.ballman

Subscribers: llvm-commits

Differential Revision: https://reviews.llvm.org/D54915

This reverts commit a5b3c232d1e3613f23efbc3960f8e23ea70f2a79.
(r347617)

llvm-svn: 347628
2018-11-27 02:22:00 +00:00
Zola Bridges 3b47649fa8 [clang][slh] add attribute for speculative load hardening
Summary:
The prior diff had to be reverted because there were two tests
that failed. I updated the two tests in this diff

clang/test/Misc/pragma-attribute-supported-attributes-list.test
clang/test/SemaCXX/attr-speculative-load-hardening.cpp

----- Summary from Previous Diff (Still Accurate) -----

LLVM IR already has an attribute for speculative_load_hardening. Before
this commit, when a user passed the -mspeculative-load-hardening flag to
Clang, every function would have this attribute added to it. This Clang
attribute will allow users to opt into SLH on a function by function basis.

This can be applied to functions and Objective C methods.

Reviewers: chandlerc, echristo, kristof.beyls, aaron.ballman

Subscribers: llvm-commits

Differential Revision: https://reviews.llvm.org/D54915

llvm-svn: 347617
2018-11-27 00:03:44 +00:00
Zola Bridges e8e8c5cf4d Revert "[clang][slh] add attribute for speculative load hardening"
This reverts commit 801eaf91221ba6dd6996b29ff82659ad6359e885.

llvm-svn: 347588
2018-11-26 20:11:18 +00:00
Zola Bridges b0fd2db8fc [clang][slh] add attribute for speculative load hardening
Summary:
LLVM IR already has an attribute for speculative_load_hardening. Before
this commit, when a user passed the -mspeculative-load-hardening flag to
Clang, every function would have this attribute added to it. This Clang
attribute will allow users to opt into SLH on a function by function basis.

This can be applied to functions and Objective C methods.

Reviewers: chandlerc, echristo

Subscribers: llvm-commits

Differential Revision: https://reviews.llvm.org/D54555

llvm-svn: 347586
2018-11-26 19:41:14 +00:00
Leonard Chan 9ede953abc [Docs] Documentation for the saturation addition and subtraction intrinsics
Differential Revision: https://reviews.llvm.org/D54729

llvm-svn: 347334
2018-11-20 18:01:24 +00:00
Cameron McInally e4ee9849c0 [FNeg] Add FNeg Instruction to LangRef document
The FNeg IR Instruction code was added with D53877.

Differential Revision: https://reviews.llvm.org/D54549

llvm-svn: 347086
2018-11-16 19:52:59 +00:00
Vedant Kumar 808e157356 Mark @llvm.trap cold
A call to @llvm.trap can be expected to be cold (i.e. unlikely to be
reached in a normal program execution).

Outlining paths which unconditionally trap is an important memory
saving. As the hot/cold splitting pass (imho) should not treat all
noreturn calls as cold, explicitly mark @llvm.trap cold so that it can
be outlined.

Split out of https://reviews.llvm.org/D54244.

Differential Revision: https://reviews.llvm.org/D54329

llvm-svn: 346885
2018-11-14 19:53:41 +00:00
James Y Knight 72f76bf230 Add support for llvm.is.constant intrinsic (PR4898)
This adds the llvm-side support for post-inlining evaluation of the
__builtin_constant_p GCC intrinsic.

Also fixed SCCPSolver::visitCallSite to not blow up when seeing a call
to a function where canConstantFoldTo returns true, and one of the
arguments is a struct.

Updated from patch initially by Janusz Sobczak.

Differential Revision: https://reviews.llvm.org/D4276

llvm-svn: 346322
2018-11-07 15:24:12 +00:00
Cameron McInally 9757d5d6c1 [FPEnv] Add constrained CEIL/FLOOR/ROUND/TRUNC intrinsics
Differential Revision: https://reviews.llvm.org/D53411

llvm-svn: 346141
2018-11-05 15:59:49 +00:00
Cameron McInally 1005679ac1 [NFC] Remove some extra characters from docs/LangRef.rst
llvm-svn: 345987
2018-11-02 15:51:43 +00:00
Mandeep Singh Grang 547a0d765a [COFF, ARM64] Implement Intrinsic.sponentry for AArch64
Summary: This patch adds Intrinsic.sponentry. This intrinsic is required to correctly support setjmp for AArch64 Windows platform.

Patch by: Yin Ma (yinma@codeaurora.org)

Reviewers: mgrang, ssijaric, eli.friedman, TomTan, mstorsjo, rnk, compnerd, efriedma

Reviewed By: efriedma

Subscribers: efriedma, javed.absar, kristof.beyls, chrib, llvm-commits

Differential Revision: https://reviews.llvm.org/D53996

llvm-svn: 345909
2018-11-01 23:22:25 +00:00
Mandeep Singh Grang df19e57a1c [COFF, ARM64] Implement llvm.addressofreturnaddress intrinsic
Reviewers: rnk, mstorsjo, efriedma, TomTan

Reviewed By: efriedma

Subscribers: javed.absar, kristof.beyls, chrib, llvm-commits

Differential Revision: https://reviews.llvm.org/D53962

llvm-svn: 345892
2018-11-01 21:23:47 +00:00
Mandeep Singh Grang b0cdf56dd7 Revert "[COFF, ARM64] Implement Intrinsic.sponentry for AArch64"
This reverts commit 585b6667b4712e3c7f32401e929855b3313b4ff2.

llvm-svn: 345863
2018-11-01 17:53:57 +00:00
Mandeep Singh Grang 88ad9ac720 [COFF, ARM64] Implement Intrinsic.sponentry for AArch64
Summary: This patch adds Intrinsic.sponentry. This intrinsic is required to correctly support setjmp for AArch64 Windows platform.

Reviewers: mgrang, TomTan, rnk, compnerd, mstorsjo, efriedma

Reviewed By: efriedma

Subscribers: majnemer, chrib, javed.absar, kristof.beyls, llvm-commits

Differential Revision: https://reviews.llvm.org/D53673

llvm-svn: 345791
2018-10-31 23:16:20 +00:00
Cameron McInally 2ad870e785 [FPEnv] [FPEnv] Add constrained intrinsics for MAXNUM and MINNUM
Differential Revision: https://reviews.llvm.org/D53216

llvm-svn: 345650
2018-10-30 21:01:29 +00:00
Kristina Brooks 312fcc116b [X86] Support for the mno-tls-direct-seg-refs flag
Allows to disable direct TLS segment access (%fs or %gs). GCC supports
a similar flag, it can be useful in some circumstances, e.g. when a thread
context block needs to be updated directly from user space. More info
and specific use cases: https://bugs.llvm.org/show_bug.cgi?id=16145

There is another revision for clang as well.
Related: D53102

All X86 CodeGen tests appear to pass:
```
[46/47] Running lit suite /SourceCache/llvm-trunk-8.0/test/CodeGen
Testing Time: 23.17s
  Expected Passes    : 3801
  Expected Failures  : 15
  Unsupported Tests  : 8021
```

Reviewed by: Craig Topper.

Patch by nruslan (Ruslan Nikolaev).

Differential Revision: https://reviews.llvm.org/D53103

llvm-svn: 344723
2018-10-18 03:14:37 +00:00
Thomas Lively 16c349d892 [Intrinsic] Add llvm.minimum and llvm.maximum instrinsic functions
Summary:
These new intrinsics have the semantics of the `minimum` and `maximum`
operations specified by the latest draft of IEEE 754-2018. Unlike
llvm.minnum and llvm.maxnum, these new intrinsics propagate NaNs and
always treat -0.0 as less than 0.0. `minimum` and `maximum` lower
directly to the existing `fminnan` and `fmaxnan` ISel DAG nodes. It is
safe to reuse these DAG nodes because before this patch were only
emitted in situations where there were known to be no NaN arguments or
where NaN propagation was correct and there were known to be no zero
arguments. I know of only four backends that lower fminnan and
fmaxnan: WebAssembly, ARM, AArch64, and SystemZ, and each of these
lowers fminnan and fmaxnan to instructions that are compatible with
the IEEE 754-2018 semantics.

Reviewers: aheejin, dschuff, sunfish, javed.absar

Subscribers: kristof.beyls, dexonsmith, kristina, llvm-commits

Differential Revision: https://reviews.llvm.org/D52764

llvm-svn: 344437
2018-10-13 07:21:44 +00:00
Teresa Johnson ab2a7f0f69 [ThinLTO] Update LangRef doc for summary parsing
Summary:
Remove note about summary being ignored. Update to reflect the
fact that summary is now parsed by llvm-as.

While here, fix one summary format that changed since the initial
implementation.

Reviewers: dexonsmith

Subscribers: inglorion, llvm-commits

Differential Revision: https://reviews.llvm.org/D51540

llvm-svn: 342479
2018-09-18 13:44:13 +00:00
Chandler Carruth 664aa868f5 [x86/SLH] Add a real Clang flag and LLVM IR attribute for Speculative
Load Hardening.

Wires up the existing pass to work with a proper IR attribute rather
than just a hidden/internal flag. The internal flag continues to work
for now, but I'll likely remove it soon.

Most of the churn here is adding the IR attribute. I talked about this
Kristof Beyls and he seemed at least initially OK with this direction.
The idea of using a full attribute here is that we *do* expect at least
some forms of this for other architectures. There isn't anything
*inherently* x86-specific about this technique, just that we only have
an implementation for x86 at the moment.

While we could potentially expose this as a Clang-level attribute as
well, that seems like a good question to defer for the moment as it
isn't 100% clear whether that or some other programmer interface (or
both?) would be best. We'll defer the programmer interface side of this
for now, but at least get to the point where the feature can be enabled
without relying on implementation details.

This also allows us to do something that was really hard before: we can
enable *just* the indirect call retpolines when using SLH. For x86, we
don't have any other way to mitigate indirect calls. Other architectures
may take a different approach of course, and none of this is surfaced to
user-level flags.

Differential Revision: https://reviews.llvm.org/D51157

llvm-svn: 341363
2018-09-04 12:38:00 +00:00
Matt Arsenault 937003cf22 LangRef: Clarify expected sNaN behavior for minnum/maxnum
This matches the de-facto behavior based on constant folding
and the default lowering to fmin/fmax.

llvm-svn: 340762
2018-08-27 17:40:07 +00:00
Alexander Richardson 6bcf2ba2f0 Allow creating llvm::Function in non-zero address spaces
Most users won't have to worry about this as all of the
'getOrInsertFunction' functions on Module will default to the program
address space.

An overload has been added to Function::Create to abstract away the
details for most callers.

This is based on https://reviews.llvm.org/D37054 but without the changes to
make passing a Module to Function::Create() mandatory. I have also added
some more tests and fixed the LLParser to accept call instructions for
types in the program address space.

Reviewed By: bjope

Differential Revision: https://reviews.llvm.org/D47541

llvm-svn: 340519
2018-08-23 09:25:17 +00:00
Chandler Carruth 3a56e3f028 [docs] Stop trying to parse the ThinLTO summary IR fragments with the
`llvm` syntax in Sphinx. This appears to just fail and create errors on
the docs buildbot.

llvm-svn: 338997
2018-08-06 09:46:59 +00:00
Chandler Carruth 4a73aa112b [docs] Switch debug info metadata blocks to use `text` instead of `llvm`
highlighting syntax.

Most of them already were like this, and the Sphinx runs on the docs
build bot seems to be substantially more picky and/or not have support
for a bunch of the syntax here. Hopefully this will let it progress past
this.

My previous attempt to fix the syntax made the `opt` tool happy, but no
idea what the Sphinx stuff is really looking for, and the fact that
other blocks already just use `text` led me to this solution.

llvm-svn: 338983
2018-08-06 03:35:36 +00:00
Chandler Carruth 24dd211f05 [docs] Correct the basic syntax structure of the DISubrange example.
Notably, just close two of the debug info metadata nodes early rather
than leaving them open with `...` which won't ever lex correctly. And
add the missing `:` on the count labels.

Slowly progressing through all of the warnings on the documentation
build bot. Sorry to do this one commit at a time, but despite my best
efforts I can't trigger these errors locally.

llvm-svn: 338982
2018-08-06 02:30:01 +00:00
Chandler Carruth 297620d337 [docs] Remove an example that isn't well formed LLVM IR and trips up the
Sphinx syntax highlighter.

This example also doesn't really make sense. There is no control flow or
clarification of what the `Safe:` block exists to do... If we want
examples here, we should make them much more clear in addition to making
them well formed IR sequences.

llvm-svn: 338981
2018-08-06 02:02:09 +00:00
Vedant Kumar 8a05b01d13 [docs] Clarify role of DIExpressions within debug intrinsics
This should make the semantics of DIExpressions within llvm.dbg.{addr,
declare, value} easier to understand.

Differential Revision: https://reviews.llvm.org/D49572

llvm-svn: 338182
2018-07-28 00:33:47 +00:00
Eli Friedman 0f522bdbac [LangRef] Clarify undefined behavior for function attributes.
Violating the invariants specified by attributes is undefined behavior.
Maybe we could use poison instead for some of the parameter attributes,
but I don't think it's worthwhile.

Differential Revision: https://reviews.llvm.org/D49041

llvm-svn: 337947
2018-07-25 18:26:38 +00:00
David Green 7fbf06c10b [UnJ] Document unroll and jam pass and loop metadata
Add some quick words for unroll and jam to the list of passes and add
unroll_and_jam metadata to the language ref.

Differential Revision: https://reviews.llvm.org/D49349

llvm-svn: 337448
2018-07-19 12:37:00 +00:00
Eli Friedman e15a111ba0 [LangRef] Clarify semantics of load metadata.
We need to explicitly state what happens when an invariant promised by
load metadata is violated at runtime, since it's come up repeatedly.

It's possible we want to specify that the result of the load is poison
in some cases, rather than undefined behavior, if the constraint is
violated. That would allow preserving the metadata when the load is
hoisted, but doesn't allow propagating metadata based on control flow.
We currently do transforms based on control flow for nonnull metadata
(in PromoteMemToReg).

Differential Revision: https://reviews.llvm.org/D47854

llvm-svn: 337325
2018-07-17 20:38:11 +00:00
Eli Friedman d3a308789e [LangRef] nnan and ninf produce poison.
Clarify that violating nnan and ninf can lead to undefined behavior.
This allows more aggressive optimizations based on those assumptions.

Differential Revision: https://reviews.llvm.org/D47963

llvm-svn: 337323
2018-07-17 20:31:42 +00:00
Eli Friedman 8bb4326c04 [LangRef] Clarify which fast-math flags affect fcmp.
nsz has no effect due to the way fcmp is defined; +0 and -0 compare
equal anyway. reassoc could have the obvious effect.

llvm-svn: 337322
2018-07-17 20:28:31 +00:00
Sanjay Patel c71adc8040 [Intrinsics] define funnel shift IR intrinsics + DAG builder support
As discussed here:
http://lists.llvm.org/pipermail/llvm-dev/2018-May/123292.html
http://lists.llvm.org/pipermail/llvm-dev/2018-July/124400.html

We want to add rotate intrinsics because the IR expansion of that pattern is 4+ instructions, 
and we can lose pieces of the pattern before it gets to the backend. Generalizing the operation 
by allowing 2 different input values (plus the 3rd shift/rotate amount) gives us a "funnel shift" 
operation which may also be a single hardware instruction.

Initially, I thought we needed to define new DAG nodes for these ops, and I spent time working 
on that (much larger patch), but then I concluded that we don't need it. At least as a first 
step, we have all of the backend support necessary to match these ops...because it was required. 
And shepherding these through the IR optimizer is the primary concern, so the IR intrinsics are 
likely all that we'll ever need.

There was also a question about converting the intrinsics to the existing ROTL/ROTR DAG nodes
(along with improving the oversized shift documentation). Again, I don't think that's strictly 
necessary (as the test results here prove). That can be an efficiency improvement as a small 
follow-up patch.

So all we're left with is documentation, definition of the IR intrinsics, and DAG builder support. 

Differential Revision: https://reviews.llvm.org/D49242

llvm-svn: 337221
2018-07-16 22:59:31 +00:00
Eli Friedman 18f882c8b8 [LangRef] Clarify alloca of zero bytes.
Let's be conservative here; it matches what we actually implemented, and
it should be rare in practice anyway.

Differential Revision: https://reviews.llvm.org/D49042

llvm-svn: 336744
2018-07-11 00:02:01 +00:00
Manoj Gupta 77eeac3d9e llvm: Add support for "-fno-delete-null-pointer-checks"
Summary:
Support for this option is needed for building Linux kernel.
This is a very frequently requested feature by kernel developers.

More details : https://lkml.org/lkml/2018/4/4/601

GCC option description for -fdelete-null-pointer-checks:
This Assume that programs cannot safely dereference null pointers,
and that no code or data element resides at address zero.

-fno-delete-null-pointer-checks is the inverse of this implying that
null pointer dereferencing is not undefined.

This feature is implemented in LLVM IR in this CL as the function attribute
"null-pointer-is-valid"="true" in IR (Under review at D47894).
The CL updates several passes that assumed null pointer dereferencing is
undefined to not optimize when the "null-pointer-is-valid"="true"
attribute is present.

Reviewers: t.p.northover, efriedma, jyknight, chandlerc, rnk, srhines, void, george.burgess.iv

Reviewed By: efriedma, george.burgess.iv

Subscribers: eraman, haicheng, george.burgess.iv, drinkcat, theraven, reames, sanjoy, xbolva00, llvm-commits

Differential Revision: https://reviews.llvm.org/D47895

llvm-svn: 336613
2018-07-09 22:27:23 +00:00
George Burgess IV 3fbfa9c403 Make llvm.objectsize more conservative with null
In non-zero address spaces, we were reporting that an object at `null`
always occupies zero bytes. This is incorrect in many cases, so just
return `unknown` in those cases for now.

Differential Revision: https://reviews.llvm.org/D48860

llvm-svn: 336611
2018-07-09 22:21:16 +00:00
Piotr Padlewski 5b3db45e8f Implement strip.invariant.group
Summary:
This patch introduce new intrinsic -
strip.invariant.group that was described in the
RFC: Devirtualization v2

Reviewers: rsmith, hfinkel, nlopes, sanjoy, amharc, kuhar

Subscribers: arsenm, nhaehnle, JDevlieghere, hiraditya, xbolva00, llvm-commits

Differential Revision: https://reviews.llvm.org/D47103

Co-authored-by: Krzysztof Pszeniczny <krzysztof.pszeniczny@gmail.com>
llvm-svn: 336073
2018-07-02 04:49:30 +00:00
Hiroshi Inoue c36a1f1cb7 [NFC] fix trivial typos in documents
llvm-svn: 334799
2018-06-15 05:10:09 +00:00
Eli Friedman 3f1ce093ea Make uitofp and sitofp defined on overflow.
IEEE 754 defines the expected result on overflow. As far as I know,
hardware implementations (of f16), and compiler-rt (__floatuntisf)
correctly return +-Inf on overflow. And I can't think of any useful
transform that would take advantage of overflow being undefined here.

Differential Revision: https://reviews.llvm.org/D47807

llvm-svn: 334777
2018-06-14 22:58:48 +00:00
Eli Friedman c065bb2953 [LangRef] fptosi and fptoui return poison on overflow.
I think we assume poison, not undef, for certain transforms we
currently do. In any case, we should clarify the language here.

(This sort of conversion is undefined behavior according to the C
and C++ standards. And in practice, hardware implementations handle
overflow inconsistently, so it would be difficult to define the
result here.)

Differential Revision: https://reviews.llvm.org/D47851

llvm-svn: 334326
2018-06-08 21:33:33 +00:00
Eli Friedman 2c7a81b2f8 [LangRef] insertelement/extractelement return poison for out of range.
We need to clarify the language here. I think poison makes more sense
than undef, since it's an undefined operation rather than uninitialized
memory. I don't think anything depends on the difference at the moment,
though.

Differential Revision: https://reviews.llvm.org/D47859

llvm-svn: 334325
2018-06-08 21:23:09 +00:00
Elena Demikhovsky 0ef2ce3667 Added documentation for Masked Vector Expanding Load and Compressing Store Intrinsics
Differential Revision: https://reviews.llvm.org/D26743

llvm-svn: 334075
2018-06-06 09:11:46 +00:00
Sanjay Patel 2896c773eb [LangRef] fix typo; NFC
llvm-svn: 333770
2018-06-01 15:21:14 +00:00
Fangrui Song 74d6a7400c [LangRef] Fix TBAA example
llvm-svn: 333389
2018-05-29 05:38:05 +00:00