llvm-svn: 362399

Summary:

Remove unnecessary definition (otherwise the extension will be defined
where it's not supposed to be defined).

Consider the code:

  #pragma OPENCL EXTENSION cl_intel_planar_yuv : begin
  // some declarations
  #pragma OPENCL EXTENSION cl_intel_planar_yuv : end

is enough for extension to become known for clang.

Patch by: Dmitry Sidorov <dmitry.sidorov@intel.com>

Reviewers: Anastasia, yaxunl

Reviewed By: Anastasia

Tags: #clang

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

llvm-svn: 362398

We were missing this fold in the DAG, which I've copied directly from llvm::ConstantFoldCastInstruction

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

llvm-svn: 362397

Pre-commit for D62807 - which adds DAG [us]itofp(undef) --> 0 constant fold

llvm-svn: 362396

llvm-svn: 362395

LanaiMCCodeEmitter.cpp was not using any APIs from Lanai.h, and was only
including it for transitive dependencies.  Doing so is problematic from
include-what-you-use perspective, but it is also a layering issue (it
creates a dependency cycle between the primary Lanai target library and
the MCTargetDesc library).

llvm-svn: 362394

We need to have all input files ready before doing debuginfo type merging.
This patch is moving the late PDB type server discovery much earlier in the process, when the explicit inputs (OBJs, LIBs) are loaded.
The short term goal is to parallelize type merging.

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

llvm-svn: 362393

llvm-svn: 362392

Summary: According to C99 standard long long is at least 64 bits in
size. However, OpenCL C defines long long as 128 bit signed
integer. This prevents one to use x86 builtins when compiling OpenCL C
code for x86 targets. The patch changes long long to long for OpenCL
only.

Patch by: Alexander Batashev <alexander.batashev@intel.com>

Reviewers: craig.topper, Ka-Ka, eandrews, erichkeane, Anastasia

Reviewed By: Ka-Ka, erichkeane, Anastasia

Subscribers: a.elovikov, yaxunl, Anastasia, cfe-commits, ivankara, etyurin, asavonic

Tags: #clang

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

llvm-svn: 362391

Summary: Change-Id: If6ee98e4a723b643bc37254fc6ef8b3812db16da

Reviewers: rampitec

Subscribers: arsenm, kzhuravl, jvesely, wdng, yaxunl, dstuttard, tpr, t-tye, llvm-commits

Tags: #llvm

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

Change-Id: Id547ef152b2f92b24dc1c0efbf7e4467c4fb4b6e
llvm-svn: 362390

HexagonInstPrinter.cpp was not using any APIs from HexagonAsmPrinter.h.
Doing so is problematic from include-what-you-use perspective, but it is
also a layering issue (it creates a dependency cycle between the primary
Hexagon target library and the MCTargetDesc library).

llvm-svn: 362389

llvm-svn: 362388

HexagonMCInstrInfo.cpp was not using any APIs from Hexagon.h.  Doing so
is problematic from include-what-you-use perspective, but it is also a
layering issue (it creates a dependency cycle between the primary
Hexagon target library and the MCTargetDesc library).

llvm-svn: 362387

HexagonMCCodeEmitter.cpp was not using any APIs from Hexagon.h.  Doing
so is problematic from include-what-you-use perspective, but it is also
a layering issue (it creates a dependency cycle between the primary
Hexagon target library and the MCTargetDesc library).

llvm-svn: 362386

HexagonMCCompound.cpp was not using any APIs from Hexagon.h.  Doing so
is problematic from include-what-you-use perspective, but it is also a
layering issue (it creates a dependency cycle between the primary
Hexagon target library and the MCTargetDesc library).

llvm-svn: 362385

HexagonShuffler.cpp was not using any APIs from Hexagon.h, and was only
including it for transitive dependencies.  Doing so is problematic from
include-what-you-use perspective, but it is also a layering issue (it
creates a dependency cycle between the primary Hexagon target library
and the MCTargetDesc library).

llvm-svn: 362384

HexagonMCChecker.cpp was not using any APIs from Hexagon.h.  Doing so is
problematic from include-what-you-use perspective, but it is also a
layering issue (it creates a dependency cycle between the primary
Hexagon target library and the MCTargetDesc library).

llvm-svn: 362383

HexagonMCTargetDesc.cpp was not using any APIs from Hexagon.h.  Doing so
is problematic from include-what-you-use perspective, but it is also a
layering issue (it creates a dependency cycle between the primary
Hexagon target library and the MCTargetDesc library).

llvm-svn: 362382

HexagonMCShuffler.cpp was not using any APIs from Hexagon.h.  Doing so
is problematic from include-what-you-use perspective, but it is also a
layering issue (it creates a dependency cycle between the primary
Hexagon target library and the MCTargetDesc library).

llvm-svn: 362381

The recent change D60691 introduced a bug in clang when handling
option combinations such as `-mcpu=cortex-m4 -mfpu=none`. Those
options together should select Cortex-M4 but disable all use of
hardware FP, but in fact, now hardware FP instructions can still be
generated in that mode.

The reason is because the handling of FPUVersion::NONE disables all
the same feature names it used to, of which the base one is `vfp2`.
But now there are further features below that, like `vfp2d16fp` and
(following D60694) `fpregs`, which also need to be turned off to
disable hardware FP completely.

Added a tiny test which double-checks that compiling a simple FP
function doesn't access the FP registers.

Reviewers: SjoerdMeijer, dmgreen

Reviewed By: dmgreen

Subscribers: lebedev.ri, javed.absar, kristof.beyls, hiraditya, cfe-commits, llvm-commits

Tags: #clang, #llvm

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

llvm-svn: 362380

llvm-svn: 362379

Summary:
This patch adds tests for directives .arch, .arch_extension and .cpu for
all features defined in Arm SVE2 architecture extension.

Reviewed By: chill

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

llvm-svn: 362378

gnu-sections.test currently use relocs.obj.elf-x86_64 and
relocs.obj.elf-i386 precompiled objects as an inputs.

These inputs actually initially were introduced to test the
dump of relocations and have almost nothing common with dumping
sections.

Patch converts the test to use yaml2obj. That allows to remove
relocs.obj.elf-i386 binary.
(relocs.obj.elf-x86_64 is still used by another test and can't be removed atm).

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

llvm-svn: 362377

HexagonELFObjectWriter.cpp was not using any APIs from Hexagon.h, and
was only including it for transitive dependencies.  Doing so is
problematic from include-what-you-use perspective, but it is also a
layering issue (it creates a dependency cycle between the primary
Hexagon target library and the MCTargetDesc library).

llvm-svn: 362376

Two changes:
 * Track odr-use via FunctionParmPackExprs to properly handle dependent
   odr-uses of packs in generic lambdas.
 * Do not instantiate implicit captures; instead, regenerate them by
   instantiating the body of the lambda. This is necessary to
   distinguish between cases where only one element of a pack is
   captured and cases where the entire pack is captured.
........
Fixes http://lab.llvm.org:8011/builders/llvm-clang-x86_64-expensive-checks-win buildbot failures

llvm-svn: 362375

rL362089 introduced a set of yaml based reloc-types-*.test test cases
(instead of huge reloc-types.test that used a lot of precompiled binaries)
These test cases checks LLVM-styled dumping of the relocations.

gnu-relocations.test was a test case to check GNU styled relocations dumping.
It did that only for elf-x86 and elf-x86_64 targets. It did not test all of the
relocations though.

Now, after rL362089, it does not make sence to keep it.
This patch updates reloc-types-elf-i386.test and reloc-types-elf-x64.test tests
with llvm-readelf calls to check GNU styled output in one place.
It removes gnu-relocations.test completely.

One of intentions of doing this is also to get rid of relocs.obj.elf-i386 and
relocs.obj.elf-x86_64 precompiled objects completely (they are used in other tests still).

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

llvm-svn: 362374

When LiveDebugValues deduces new variable's location from spill, restore or
register copy instruction it should close old variable's location. Otherwise
we can have multiple block output locations for same variable. That could lead
to inserting two DBG_VALUEs for same variable to the beginning of the successor
block which results to ignoring of first DBG_VALUE.

Reviewers: aprantl, jmorse, wolfgangp, dstenb

Reviewed By: aprantl

Subscribers: probinson, asowda, ivanbaev, petarj, djtodoro

Tags: #debug-info

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

llvm-svn: 362373

HexagonAsmBackend.cpp was not using any APIs from Hexagon.h.  Doing so
is problematic from include-what-you-use perspective, but it is also a
layering issue (it creates a dependency cycle between the primary
Hexagon target library and the MCTargetDesc library).

llvm-svn: 362372

This patch adds a `-fdeclare-opencl-builtins` command line option to
the clang frontend.  This enables clang to verify OpenCL C builtin
function declarations using a fast StringMatcher lookup, instead of
including the opencl-c.h file with the `-finclude-default-header`
option.  This avoids the large parse time penalty of the header file.

This commit only adds the basic infrastructure and some of the OpenCL
builtins.  It does not cover all builtins defined by the various OpenCL
specifications.  As such, it is not a replacement for
`-finclude-default-header` yet.

RFC: http://lists.llvm.org/pipermail/cfe-dev/2018-November/060041.html

Co-authored-by: Pierre Gondois
Co-authored-by: Joey Gouly
Co-authored-by: Sven van Haastregt

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

llvm-svn: 362371

HexagonAsmParser.cpp was not using any APIs from Hexagon.h.  Doing so is
problematic from include-what-you-use perspective, but it is also a
layering issue (it creates a dependency cycle between the primary
Hexagon target library and the AsmParser library).

llvm-svn: 362370

HexagonShuffler.h was not using any APIs from Hexagon.h, and was only
including it for transitive dependencies.  Doing so is problematic from
include-what-you-use perspective, but it is also a layering issue (it
creates a dependency cycle between the primary Hexagon target library
and the MCTargetDesc library).

llvm-svn: 362369

BPFMCTargetDesc.cpp was not using any APIs from BPF.h.  Doing so is
problematic from include-what-you-use perspective, but it is also a
layering issue (it creates a dependency cycle between the primary
BPF target library and the MCTargetDesc library).

llvm-svn: 362368

I believe this line was dead after r362356.

llvm-svn: 362367

Summary:
- pr42062
When compiling for MinSize,
ARMTargetLowering::LowerCall decides to indirect
multiple calls to a same function. However,
it disconsiders the limitation that thumb1
indirect calls require the callee to be in a
register from r0 to r3 (llvm limiation).
If all those registers are used by arguments, the
compiler dies with "error: run out of registers
during register allocation".
This patch tells the function
IsEligibleForTailCallOptimization if we intend to
perform indirect calls, as to avoid tail call
optimization.

Reviewers: dmgreen, efriedma

Reviewed By: efriedma

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

Tags: #llvm

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

llvm-svn: 362366

DAGCombiner was hitting a SimpleType assertion when trying to combine
a v3f32 before type legalization.

bugzilla: https://bugs.llvm.org/show_bug.cgi?id=41916

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

llvm-svn: 362365

llvm-svn: 362364

Summary:
E.g. we now turn `while(<#cond#>){` into `while (<#cond#>) {`

This slightly improves the final output. Should not affect clients that
format the result on their own.

Reviewers: gribozavr

Reviewed By: gribozavr

Subscribers: jkorous, arphaman, kadircet, cfe-commits

Tags: #clang

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

llvm-svn: 362363

A test commit from Mikhail Dvorskiy (blank line, to pstl/trunk) according 'Obtaining Commit Access' rules (https://llvm.org/docs/DeveloperPolicy.html#obtaining-commit-access)

llvm-svn: 362362

Summary:
Previously, we intended to omit the check fix to the case when constructor has
any braced-init-list argument. But the HasListInitializedArgument was not
correct to handle all cases (Foo(Bar{1, 2}) will return false in C++14
mode).

This patch fixes it, corrects the tests, and makes the check to run at C++17 mode.

Reviewers: gribozavr

Subscribers: xazax.hun, cfe-commits

Tags: #clang

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

llvm-svn: 362361

A std::array is implemented as a template with an array inside a struct.
Older versions of clang, like 3.6, require an extra set of curly braces
around std::array initializations to avoid warnings.

The C++ language was changed regarding this by CWG 1270. So more modern
tool chains does not complain even if leaving out one level of braces.

llvm-svn: 362360