llvm-svn: 293756

[clang-format] Fix regression about not aligning trailing comments in case they were previously aligned, but at different indent.

Summary:
Comment reflower was adding untouchable tokens in case two consecutive comment lines are aligned in the source code. This disallows the whitespace manager to re-indent them later.

source:
```
int i = f(abc, // line 1
          d, // line 2
	     // line 3
	  b);
```
Since line 2 and line 3 are aligned, the reflower was marking line 3 as untouchable; however the three comment lines need to be re-aligned.
output before:
```
int i = f(abc, // line 1
          d,   // line 2
	     // line 3
	  b);
```
output after:
```
int i = f(abc, // line 1
          d,   // line 2
	       // line 3
	  b);
```

Reviewers: djasper

Reviewed By: djasper

Subscribers: sammccall, cfe-commits, klimek

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

llvm-svn: 293755

llvm-svn: 293754

llvm-svn: 293753

This rows back on r288120, r291801 and r292110. I apologize in advance
for the churn. All of those revisions where meant to make the wrapping
of RHS expressions more consistent. However, now that they are
consistent, we seem to be a bit too eager.

The reasoning here is that I think it is generally correct that we want
to line-wrap before multiline RHS expressions (or multiline arguments to
a function call). However, if there are only two of such operands or
arguments, there is always a clear vertical separation between them and
the additional line break seems much less desirable.

Somewhat good examples are expressions like:

  EXPECT_EQ(2, someLongExpression(
                   orCall));

llvm-svn: 293752

llvm-svn: 293751

Accidentally lost the commit title and message,
will recommit.

llvm-svn: 293750

llvm-svn: 293749

This is alternative to D28857 which was incorrect.

One of linux scripts contains:

vvar_start = . - 2 * (1 << 12);
vvar_page = vvar_start;
vvar_vsyscall_gtod_data = vvar_page + 128;
Previously we did not mark first expression as non-absolute,
though it contains location counter.

And LLD failed with error:
relocation R_X86_64_PC32 cannot refer to absolute symbol

This patch should fix the issue, and opens road for doing the same for other operators
(though not clear if that is needed).

Differential revision: https://reviews.llvm.org/D29332

llvm-svn: 293748

Fixed compilation warning in libomptarget.

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

llvm-svn: 293747

llvm-svn: 293746

Added doxygen comments to prfchwintrin.h's intrinsics. 

Note: The doxygen comments are automatically generated based on Sony's intrinsic
s document.

I got an OK from Eric Christopher to commit doxygen comments without prior code
review upstream.

llvm-svn: 293745

llvm-svn: 293744

For SSE we use fp because of the smaller encoding, but that doesn't apply to AVX. So just do the natural thing so we don't have to explain why we aren't. We can't do this for 256-bit loads/stores since integer loads and stores aren't available in AVX1 so we need fallback patterns since the integer types are legal.

This doesn't affect any tests because execution domain fixing freely converts the instructions anyway. Honestly, we could probably rely on it for the SSE size optimization too.

llvm-svn: 293743

Mac OS X 10.11, El Capitan, released c. Oct 2015) I conditionalized
the use of the framework on "if sdk == macosx 10.11".  But since
macOS 10.12 has shipped this year, the framework was no longer being
built in.  I can either start listing every OS 10.11 and newer, or
remove the version check.

This will break building lldb with xcodebuild / Xcode for people 
running Mac OS X 10.10 or older.  If so, I'll back this change out.
I'm not sure if we have many people working on macs running the
older OSes on their build systems.

<rdar://problem/30159130> 

llvm-svn: 293742

This basically already worked other than weak symbols needing
definitions on darwin.

llvm-svn: 293741

Contrary to the comment, DeclContext intends to guarantee that the lookup
results for a particular name will be stable across non-AST-mutating
operations, so a copy here should not be necessary. Further, if a copy *is*
necessary, the other four instances of this pattern within this file would also
be wrong, and we have no evidence of any problems with them; if this change
unearths problems, we should fix all the instances of this pattern.

llvm-svn: 293740

This feature enables the fusion of such operations on Cortex A57, as
recommended in its Software Optimisation Guide, sections 4.14 and 4.15.

Differential revision: https://reviews.llvm.org/D28698

llvm-svn: 293739

This feature enables the fusion of such operations on Cortex A57, as
recommended in its Software Optimisation Guide, section 4.13, and on Exynos
M1.

Differential revision: https://reviews.llvm.org/D28491

llvm-svn: 293738

This patch moves the class for scheduling adjacent instructions,
MacroFusion, to the target.

In AArch64, it also expands the fusion to all instructions pairs in a
scheduling block, beyond just among the predecessors of the branch at the
end.

Differential revision: https://reviews.llvm.org/D28489

llvm-svn: 293737

Summary:
isSuitableMemoryOp method is repsonsible for verification
that instruction is a candidate to use in implicit null check.
Additionally it checks that base register is not re-defined before.
In case base has been re-defined it just returns false and lookup
is continued while any suitable instruction will not succeed this check
as well. This results in redundant further operations.

So when we found that base register has been re-defined we just
stop.

Patch by Serguei Katkov!

Reviewers: reames, sanjoy

Reviewed By: sanjoy

Subscribers: llvm-commits

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

llvm-svn: 293736

llvm-svn: 293735

This works as of "Support sanitizer guard section on darwin" in the
llvm repo.

llvm-svn: 293734

MachO's sections need a segment as well as a section name, and the
section start and end symbols are spelled differently than on ELF.

llvm-svn: 293733

clang-cl would evaluate the arguments right-to-left (see PR), and for
non-Windows targets I suppose we only got it because we were already
emitting left-to-right in CodeGenFunction::EmitCallArgs.

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

llvm-svn: 293732

After this commint, we can include sancov_flags.h and refer to
__sancov_default_options without requiring the namespace prefix.

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

llvm-svn: 293731

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

llvm-svn: 293730

llvm-svn: 293729

SplitEditor::defFromParent() can create a register copy.
If register is a tuple of other registers and not all lanes are used
a copy will be done on a full tuple regardless. Later register unit
for an unused lane will be considered free and another overlapping
register tuple can be assigned to a different value even though first
register is live at that point. That is because interference only look at
liveness info, while full register copy clobbers all lanes, even unused.

This patch fixes copy to only cover used lanes.

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

llvm-svn: 293728

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

llvm-svn: 293727

Use a more specific subtarget check and combine hasOneUse checks

llvm-svn: 293726

This change should appease the mingw32 builds.

Follow-up to D29319.

llvm-svn: 293725

This is the patch upstreaming the plugins part of libomptarget (CUDA, generic-elf-64).

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

llvm-svn: 293724

This fails to handle some cases where one of the inputs is
a constant to be fixed in a later commit.

llvm-svn: 293723

llvm-svn: 293722

Summary:
This change implements the instrumentation map loading library which can
understand both YAML-defined instrumentation maps, and ELF 64-bit object
files that have the XRay instrumentation map section. We break it out
into a library on its own to allow for other applications to deal with
the XRay instrumentation map defined in XRay-instrumented binaries.

This type provides both raw access to the logical representation of the
instrumentation map entries as well as higher level functions for
converting a function ID into a function address.

At this point we only support ELF64 binaries and YAML-defined XRay
instrumentation maps. Future changes should extend this to support
32-bit ELF binaries, as well as other binary formats (like MachO).

As part of this change we also migrate all uses of the extraction logic
that used to be defined in tools/llvm-xray/ to use this new type and
interface for loading from files. We also remove the flag from the
`llvm-xray` tool that required users to specify the type of the
instrumentation map file being provided to instead make the library
auto-detect the file type.

Reviewers: dblaikie

Subscribers: mgorny, varno, llvm-commits

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

llvm-svn: 293721

llvm-svn: 293720

llvm-svn: 293719

llvm-svn: 293718

llvm-svn: 293717