[Alignment][NFC] Convert LoadInst to MaybeAlign

Summary:
This is patch is part of a series to introduce an Alignment type.
See this thread for context: http://lists.llvm.org/pipermail/llvm-dev/2019-

[Alignment][NFC] Convert LoadInst to MaybeAlign

Summary:
This is patch is part of a series to introduce an Alignment type.
See this thread for context: http://lists.llvm.org/pipermail/llvm-dev/2019-July/133851.html
See this patch for the introduction of the type: https://reviews.llvm.org/D64790

Reviewers: courbet

Subscribers: hiraditya, jfb, llvm-commits

Tags: #llvm

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

llvm-svn: 375498

show more ...

[Alignment][NFC] Remove dependency on GlobalObject::setAlignment(unsigned)

Summary:
This is patch is part of a series to introduce an Alignment type.
See this thread for context: http://lists.llvm.o

[Alignment][NFC] Remove dependency on GlobalObject::setAlignment(unsigned)

Summary:
This is patch is part of a series to introduce an Alignment type.
See this thread for context: http://lists.llvm.org/pipermail/llvm-dev/2019-July/133851.html
See this patch for the introduction of the type: https://reviews.llvm.org/D64790

Reviewers: courbet

Subscribers: arsenm, mehdi_amini, jvesely, nhaehnle, hiraditya, steven_wu, dexonsmith, dang, llvm-commits

Tags: #llvm

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

llvm-svn: 374880

show more ...

Add FMF to vector ops for phi

Summary: Small amendment to handle vector cases for D67564.

Reviewers: spatel, eli.friedman, hfinkel, cameron.mcinally, arsenm, jmolloy, bogner

Reviewed By: cameron.m

Add FMF to vector ops for phi

Summary: Small amendment to handle vector cases for D67564.

Reviewers: spatel, eli.friedman, hfinkel, cameron.mcinally, arsenm, jmolloy, bogner

Reviewed By: cameron.mcinally, bogner

Subscribers: llvm-commits, efriedma, reames, bogner, wdng

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

llvm-svn: 374794

show more ...

[Bitcode] Update naming of UNOP_NEG to UNOP_FNEG

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

llvm-svn: 373958

[IR] allow fast-math-flags on phi of FP values (2nd try)

The changes here are based on the corresponding diffs for allowing FMF on 'select':
D61917 <https://reviews.llvm.org/D61917>

As discussed th

[IR] allow fast-math-flags on phi of FP values (2nd try)

The changes here are based on the corresponding diffs for allowing FMF on 'select':
D61917 <https://reviews.llvm.org/D61917>

As discussed there, we want to have fast-math-flags be a property of an FP value
because the alternative (having them on things like fcmp) leads to logical
inconsistency such as:
https://bugs.llvm.org/show_bug.cgi?id=38086

The earlier patch for select made almost no practical difference because most
unoptimized conditional code begins life as a phi (based on what I see in clang).
Similarly, I don't expect this patch to do much on its own either because
SimplifyCFG promptly drops the flags when converting to select on a minimal
example like:
https://bugs.llvm.org/show_bug.cgi?id=39535

But once we have this plumbing in place, we should be able to wire up the FMF
propagation and start solving cases like that.

The change to RecurrenceDescriptor::AddReductionVar() is required to prevent a
regression in a LoopVectorize test. We are intersecting the FMF of any
FPMathOperator there, so if a phi is not properly annotated, new math
instructions may not be either. Once we fix the propagation in SimplifyCFG, it
may be safe to remove that hack.

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

llvm-svn: 372878

show more ...

Revert [IR] allow fast-math-flags on phi of FP values

This reverts r372866 (git commit dec03223a97af0e4dfcb23da55c0f7f8c9b62d00)

llvm-svn: 372868

[IR] allow fast-math-flags on phi of FP values

The changes here are based on the corresponding diffs for allowing FMF on 'select':
D61917

As discussed there, we want to have fast-math-flags be a pr

[IR] allow fast-math-flags on phi of FP values

The changes here are based on the corresponding diffs for allowing FMF on 'select':
D61917

As discussed there, we want to have fast-math-flags be a property of an FP value
because the alternative (having them on things like fcmp) leads to logical
inconsistency such as:
https://bugs.llvm.org/show_bug.cgi?id=38086

The earlier patch for select made almost no practical difference because most
unoptimized conditional code begins life as a phi (based on what I see in clang).
Similarly, I don't expect this patch to do much on its own either because
SimplifyCFG promptly drops the flags when converting to select on a minimal
example like:
https://bugs.llvm.org/show_bug.cgi?id=39535

But once we have this plumbing in place, we should be able to wire up the FMF
propagation and start solving cases like that.

The change to RecurrenceDescriptor::AddReductionVar() is required to prevent a
regression in a LoopVectorize test. We are intersecting the FMF of any
FPMathOperator there, so if a phi is not properly annotated, new math
instructions may not be either. Once we fix the propagation in SimplifyCFG, it
may be safe to remove that hack.

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

llvm-svn: 372866

show more ...

Add AutoUpgrade function to add new address space datalayout string to existing datalayouts.

Summary:
Add function to AutoUpgrade to change the datalayout of old X86 datalayout strings.
This adds "-

Add AutoUpgrade function to add new address space datalayout string to existing datalayouts.

Summary:
Add function to AutoUpgrade to change the datalayout of old X86 datalayout strings.
This adds "-p270:32:32-p271:32:32-p272:64:64" to X86 datalayouts that are otherwise valid
and don't already contain it.

This also removes the compatibility changes in https://reviews.llvm.org/D66843.
Datalayout change in https://reviews.llvm.org/D64931.

Reviewers: rnk, echristo

Subscribers: hiraditya, llvm-commits

Tags: #llvm

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

llvm-svn: 372267

show more ...

[BitcodeReader] Check if we can create a null constant for type.

We cannot create null constants for certain types, e.g. VoidTy,
FunctionTy or LabelTy. getNullValue asserts if we pass in an
unsuppor

[BitcodeReader] Check if we can create a null constant for type.

We cannot create null constants for certain types, e.g. VoidTy,
FunctionTy or LabelTy. getNullValue asserts if we pass in an
unsupported type. We should also check for opaque types, but I'm not
sure how.

This fixes https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=14795.

Reviewers: t.p.northover, jfb, vsk

Reviewed By: vsk

Tags: #llvm

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

llvm-svn: 369557

show more ...

[llvm] Migrate llvm::make_unique to std::make_unique

Now that we've moved to C++14, we no longer need the llvm::make_unique
implementation from STLExtras.h. This patch is a mechanical replacement
of

[llvm] Migrate llvm::make_unique to std::make_unique

Now that we've moved to C++14, we no longer need the llvm::make_unique
implementation from STLExtras.h. This patch is a mechanical replacement
of (hopefully) all the llvm::make_unique instances across the monorepo.

llvm-svn: 369013

show more ...

[AutoUpgrader] Make ArcRuntime Autoupgrader more conservative

Summary:
This is a tweak to r368311 and r368646 which auto upgrades the calls to
objc runtime functions to objc runtime intrinsics, in o

[AutoUpgrader] Make ArcRuntime Autoupgrader more conservative

Summary:
This is a tweak to r368311 and r368646 which auto upgrades the calls to
objc runtime functions to objc runtime intrinsics, in order to make sure
that the auto upgrader does not trigger with up-to-date bitcode.

It is possible for bitcode that is up-to-date to contain direct calls to
objc runtime function and those are not inserted by compiler as part of
ARC and they should not be upgraded. Now auto upgrader only triggers as
when the old style of ARC marker is used so it is guaranteed that it
won't trigger on update-to-date bitcode.

This also means it won't do this upgrade for bitcode from llvm-8 and
llvm-9, which preserves the behavior of those releases. Ideally they
should be upgraded as well but it is more important to make sure
AutoUpgrader will not trigger on up-to-date bitcode.

Reviewers: ahatanak, rjmccall, dexonsmith, pete

Reviewed By: dexonsmith

Subscribers: hiraditya, jkorous, llvm-commits

Tags: #llvm

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

llvm-svn: 368730

show more ...

[ObjC][ARC] Upgrade calls to ARC runtime functions to intrinsic calls if
the bitcode has the arm64 retainAutoreleasedReturnValue marker

The ARC middle-end passes stopped optimizing or transforming b

[ObjC][ARC] Upgrade calls to ARC runtime functions to intrinsic calls if
the bitcode has the arm64 retainAutoreleasedReturnValue marker

The ARC middle-end passes stopped optimizing or transforming bitcode
that has been compiled with old compilers after we started emitting
calls to ARC runtime functions as intrinsic calls instead of normal
function calls in the front-end and made changes to teach the ARC
middle-end passes about those intrinsics (see r349534). This patch
converts calls to ARC runtime functions that are not intrinsic functions
to intrinsic function calls if the bitcode has the arm64
retainAutoreleasedReturnValue marker. Checking for the presence of the
marker is necessary to make sure we aren't changing ARC function calls
that were originally MRR message sends (see r349952).

rdar://problem/53280660

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

llvm-svn: 368311

show more ...

ARM MTE stack sanitizer.

Add "memtag" sanitizer that detects and mitigates stack memory issues
using armv8.5 Memory Tagging Extension.

It is similar in principle to HWASan, which is a software impl

ARM MTE stack sanitizer.

Add "memtag" sanitizer that detects and mitigates stack memory issues
using armv8.5 Memory Tagging Extension.

It is similar in principle to HWASan, which is a software implementation
of the same idea, but there are enough differencies to warrant a new
sanitizer type IMHO. It is also expected to have very different
performance properties.

The new sanitizer does not have a runtime library (it may grow one
later, along with a "debugging" mode). Similar to SafeStack and
StackProtector, the instrumentation pass (in a follow up change) will be
inserted in all cases, but will only affect functions marked with the
new sanitize_memtag attribute.

Reviewers: pcc, hctim, vitalybuka, ostannard

Subscribers: srhines, mehdi_amini, javed.absar, kristof.beyls, hiraditya, cryptoad, steven_wu, dexonsmith, cfe-commits, llvm-commits

Tags: #clang, #llvm

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

llvm-svn: 366123

show more ...

Recommit "[BitcodeReader] Validate OpNum, before accessing Record array."

This recommits r365750 (git commit 8b222ecf2769ee133691f208f6166ce118c4a164)

Original message:

Currently invalid bitcod

Recommit "[BitcodeReader] Validate OpNum, before accessing Record array."

This recommits r365750 (git commit 8b222ecf2769ee133691f208f6166ce118c4a164)

Original message:

Currently invalid bitcode files can cause a crash, when OpNum exceeds
the number of elements in Record, like in the attached bitcode file.

The test case was generated by clusterfuzz: https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=15698

Reviewers: t.p.northover, thegameg, jfb

Reviewed By: jfb

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

llvm-svn: 365750jkkkk

llvm-svn: 366018

show more ...

[BitcodeReader] Use tighter upper bound to validate forward references.

At the moment, bitcode files with invalid forward reference can easily
cause the bitcode reader to run out of memory, by creat

[BitcodeReader] Use tighter upper bound to validate forward references.

At the moment, bitcode files with invalid forward reference can easily
cause the bitcode reader to run out of memory, by creating a forward
reference with a very high index.

We can use the size of the bitcode file as an upper bound, because a
valid bitcode file can never contain more records. This should be
sufficient to fail early in most cases. The only exception is large
files with invalid forward references close to the file size.

There are a couple of clusterfuzz runs that fail with out-of-memory
because of very high forward references and they should be fixed by this
patch.

A concrete example for this is D64507, which causes out-of-memory on
systems with low memory, like the hexagon upstream bots.

Reviewers: t.p.northover, thegameg, jfb, efriedma, hfinkel

Reviewed By: jfb

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

llvm-svn: 366017

show more ...

[Attributor] Deduce "nosync" function attribute.

Introduce and deduce "nosync" function attribute to indicate that a function
does not synchronize with another thread in a way that other thread migh

[Attributor] Deduce "nosync" function attribute.

Introduce and deduce "nosync" function attribute to indicate that a function
does not synchronize with another thread in a way that other thread might free memory.

Reviewers: jdoerfert, jfb, nhaehnle, arsenm

Subscribers: wdng, hfinkel, nhaenhle, mehdi_amini, steven_wu,
dexonsmith, arsenm, uenoku, hiraditya, jfb, llvm-commits

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

llvm-svn: 365830

show more ...

Revert [BitcodeReader] Validate OpNum, before accessing Record array.

This reverts r365750 (git commit 8b222ecf2769ee133691f208f6166ce118c4a164)

llvm-dis runs out of memory while opening invalid-fc

Revert [BitcodeReader] Validate OpNum, before accessing Record array.

This reverts r365750 (git commit 8b222ecf2769ee133691f208f6166ce118c4a164)

llvm-dis runs out of memory while opening invalid-fcmp-opnum.bc on
llvm-hexagon-elf, probably because the bitcode file contains other
suspicious values.

http://lab.llvm.org:8011/builders/llvm-hexagon-elf/builds/21949

llvm-svn: 365757

show more ...

[BitcodeReader] Validate OpNum, before accessing Record array.

Currently invalid bitcode files can cause a crash, when OpNum exceeds
the number of elements in Record, like in the attached bitcode fi

[BitcodeReader] Validate OpNum, before accessing Record array.

Currently invalid bitcode files can cause a crash, when OpNum exceeds
the number of elements in Record, like in the attached bitcode file.

The test case was generated by clusterfuzz: https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=15698

Reviewers: t.p.northover, thegameg, jfb

Reviewed By: jfb

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

llvm-svn: 365750

show more ...

Add, and infer, a nofree function attribute

This patch adds a function attribute, nofree, to indicate that a function does
not, directly or indirectly, call a memory-deallocation function (e.g., fre

Add, and infer, a nofree function attribute

This patch adds a function attribute, nofree, to indicate that a function does
not, directly or indirectly, call a memory-deallocation function (e.g., free,
C++'s operator delete).

Reviewers: jdoerfert

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

llvm-svn: 365336

show more ...

[ThinLTO] Attempt to recommit r365188 after alignment fix

llvm-svn: 365215

Reverted r365188 due to alignment problems on i686-android

llvm-svn: 365206

Scalable Vector IR Type with further LTO fixes

Reintroduces the scalable vector IR type from D32530, after it was reverted
a couple of times due to increasing chromium LTO build times. This latest
i

Scalable Vector IR Type with further LTO fixes

Reintroduces the scalable vector IR type from D32530, after it was reverted
a couple of times due to increasing chromium LTO build times. This latest
incarnation removes the walk over aggregate types from the verifier entirely,
in favor of rejecting scalable vectors in the isValidElementType methods in
ArrayType and StructType. This removes the 70% degradation observed with
the second repro tarball from PR42210.

Reviewers: thakis, hans, rengolin, sdesmalen

Reviewed By: sdesmalen

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

llvm-svn: 365203

show more ...

[ThinLTO] Attempt to recommit r365040 after caching fix

It's possible that some function can load and store the same
variable using the same constant expression:

store %Derived* @foo, %Derived** bi

[ThinLTO] Attempt to recommit r365040 after caching fix

It's possible that some function can load and store the same
variable using the same constant expression:

store %Derived* @foo, %Derived** bitcast (%Base** @bar to %Derived**)
%42 = load %Derived*, %Derived** bitcast (%Base** @bar to %Derived**)

The bitcast expression was mistakenly cached while processing loads,
and never examined later when processing store. This caused @bar to
be mistakenly treated as read-only variable. See load-store-caching.ll.

llvm-svn: 365188

show more ...

Fix -Wdocumentation param warning.

Don't put the full stop at the end of a param name - it confuses the doxygen parser

llvm-svn: 365128

Revert [ThinLTO] Optimize writeonly globals out

This reverts r365040 (git commit 5cacb914758c7f436b47c8362100f10cef14bbc4)

Speculatively reverting, since this appears to have broken check-lld on
Li

Revert [ThinLTO] Optimize writeonly globals out

This reverts r365040 (git commit 5cacb914758c7f436b47c8362100f10cef14bbc4)

Speculatively reverting, since this appears to have broken check-lld on
Linux. Partial analysis in https://crbug.com/981168.

llvm-svn: 365097

show more ...