They were breaking the Windows build when using MSBuild, see the
discussion on D56781.

r351833: "Use response file when generating LLVM-C.dll"

> Use response file when generating LLVM-C.dll
>
> As discovered in D56774 the command line gets to long, so use a response file to give the script the libs. This change has been tested and is confirmed working for me.
>
> Commited on behalf of Jakob Bornecrantz
>
> Differential Revision: https://reviews.llvm.org/D56781

r352250: "Build LLVM-C.dll by default on windows and enable in release package"

>  Build LLVM-C.dll by default on windows and enable in release package
>
>  With the fixes to the building of LLVM-C.dll in D56781 this should now
>  be safe to land. This will greatly simplify dealing with LLVM for people
>  that just want to use the C API on windows. This is a follow up from
>  D35077.
>
>  Patch by Jakob Bornecrantz!
>
>  Differential revision: https://reviews.llvm.org/D56774

llvm-svn: 352492

r352221 caused regressions in CUDA/HIP since device function may use _Float16 whereas host does not support it.
In this case host compilation should not diagnose usage of _Float16 in device functions or variables.

For now just do not diagnose _Float16 for CUDA/HIP. In the future we should have more precise check.

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

llvm-svn: 352488

Fixes tests on build environments that don't have zlib. See also r352483.

llvm-svn: 352487

This time with a fix to make gcc 4.8 happy.

llvm-svn: 352486

vlog seems to be too spammy in unittests.

llvm-svn: 352485

During the lowering of a switch that would result in the generation of a 
jump table, a range check is performed before indexing into the jump 
table, for the switch value being outside the jump table range and a 
conditional branch is inserted to jump to the default block. In case the 
default block is unreachable, this conditional jump can be omitted. This 
patch implements omitting this conditional branch for unreachable 
defaults.

Review ID: D52002
Reviewers: Hans Wennborg, Eli Freidman, Roman Lebedev

llvm-svn: 352484

Some new tests in libfuzzer have dependencies on zlib: add a feature test
for zlib so that we can add a REQUIRES field to the relevant tests.

Patch by Matthew Voss.

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

llvm-svn: 352483

`readBfdName` was removed recently.

llvm-svn: 352482

Summary:
USRs for macros were not cannonical due to usage of cursor location
instead of definition location.

Reviewers: jkorous

Subscribers: ilya-biryukov, ioeric, MaskRay, arphaman, cfe-commits

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

llvm-svn: 352481

llvm-svn: 352480

Re-enable the code to rewrite main-function signatures into
"int main(int argc, char *argv[])", but limited to only handling
the case of "int main(void)", so that it doesn't silently strip
an argument in the "int main(int argc, char *argv[], char *envp[])"
case.

This allows main to be called by C startup code, since WebAssembly
requires caller and callee signatures to match, so it can't rely
on passing main a different number of arguments than it expects.

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

llvm-svn: 352479

llvm-svn: 352478

The address isn't dynamically relocated. The object is.

llvm-svn: 352477

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

llvm-svn: 352476

This attempts to optimise negative values used in load/store operands
a little. We currently try to selct them as rr, materialising the
negative constant using a MOV/MVN pair. This instead selects ri with
an immediate of 0, forcing the add node to become a simpler sub.

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

llvm-svn: 352475

Adds note requested in D57301 and fixes some missing GOTPCREL addressmath checks

llvm-svn: 352474

When a function takes the address of a field the analyzer will no longer
assume that the function will change other fields of the enclosing structs.

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

llvm-svn: 352473

llvm-svn: 352472

This test started XPASSing with r352467, and the change in behaviour
performed by that patch does appear to fix the cause of the original XFAIL
(missing FrameIndex DBG_VALUE), which I've replicated locally with
-mtriple=powerpc64--.

I'll write this up in PR21881 which documents the XFAIL, and seek
confirmation I haven't overlooked something here.

llvm-svn: 352471

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

llvm-svn: 352470

Summary:
This patch avoids an assert in IPConstantPropagation when
there is a argument count/type mismatch between the caller and
the callee.

While this is actually UB on C-level (clang emits a warning),
the IR verifier seems to accept it. I'm not sure what other
frontends/languages might think about this, so simply bailing out
to avoid hitting an assert (in CallSiteBase<>::getArgOperand or
Value::doRAUW) seems like a simple solution.

The problem is exposed by the fact that AbstractCallSites will look
through a bitcast at the callee position of a call/invoke.

Reviewers: jdoerfert, reames, efriedma

Reviewed By: jdoerfert, efriedma

Subscribers: eli.friedman, efriedma, llvm-commits

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

llvm-svn: 352469

llvm-svn: 352468

A FrameIndex should be valid throughout a block regardless of what instructions
get selected in that block -- therefore we shouldn't harness dbg.values that
refer to FrameIndexes to an SDNode. There are numerous codegen reasons why
an SDNode never appears or doesn't become a location that a DBG_VALUE can
refer to. None of them actually affect the variable location.

Therefore, before any other tests to encode dbg_values in a SelectionDAG,
identify FrameIndex operands and encode them unattached to any SDNode.

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

llvm-svn: 352467

llvm-svn: 352466

Windows ARM64 has PIC relocation model and uses jump table kind
EK_LabelDifference32. This produces jump table entry as
".word LBB123 - LJTI1_2" which represents the distance between the block
and jump table.

A new relocation type (IMAGE_REL_ARM64_REL32) is needed to do the fixup
correctly if they are in different COFF section.

This change saves the jump table to the same COFF section as the
associated code. An ideal fix could be utilizing IMAGE_REL_ARM64_REL32
relocation type.

Patch by Tom Tan!

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

llvm-svn: 352465

Summary:
This patch adds the basic support of methods reconstruction by native PDB
plugin. It contains only most obvious changes (it processes LF_ONEMETHOD and
LF_METHOD records), some things still remain unsolved:

- mangled names retrieving;
- support of template methods.

Reviewers: zturner, labath, lemo, stella.stamenova

Reviewed by: zturner

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

llvm-svn: 352464

    
Re-applying r351740 with fixes (changing LL to W).

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

llvm-svn: 352463

This patch makes sure that a debug value that is after the bitcast in
dupRetToEnableTailCallOpts() is also skipped.

The reduced test case is from SPEC-2006 on SystemZ.

Review: Vedant Kumar, Wolfgang Pieb
https://reviews.llvm.org/D57050

llvm-svn: 352462

The existing typedef of unw_fpreg_t to uint64_t might work and be
correct for the ARM_EHABI case, but for dwarf, some cases in e.g.
DwarfInstructions.hpp convert between double and unw_fpreg_t.

When converting implicitly between double and unw_fpreg_t (uint64_t),
the values get interpreted as integers and converted to float and vice
versa, while the correct thing would be to keep the same bit pattern.

Avoid the whole issue by using the same definition of unw_fpreg_t
as all other architectures, when using dwarf unwinding on ARM.

Change assembler functions to take a void pointer instead of
unw_fpreg_t pointer, to avoid having a different mangled symbol name
depending on the actual value of this typedef.

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

llvm-svn: 352461

This should have had a target triple in it, my mistake.

llvm-svn: 352460

GCC can use LLD with -fuse-ld=lld for MinGW these days, but by
default these options are passed to the linker (unless -fno-lto
is passed to the GCC driver).

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

llvm-svn: 352459

llvm-svn: 352456

Without the fix we get the following (with -Werror):

../lib/Target/X86/X86ISelLowering.cpp:14181:58: error: suggest braces around initialization of subobject [-Werror,-Wmissing-braces]
  SmallVector<std::array<int, 2>, 2> LaneSrcs(NumLanes, {-1, -1});
                                                         ^~~~~~
                                                         {     }
1 error generated.

llvm-svn: 352455

I had a local change I hadn't realized when submitting that auto-update.  As such, the auto-update was wrong.  This should fix it, and with that, it's clearly time to stop submitting changes and go to bed.

llvm-svn: 352454

This file appears to have been manually editted at some point after being auto-updated. A future change adjusts this file slightly, and all of the updates makes the diff super confusing.

llvm-svn: 352453

[Test] Add tests for gather/maked.load demanded elements, and convert the whole file to auto generated checks.

llvm-svn: 352452

The code of AddRec simplification is using wrong loop when it creates a new
AddRecExpr. It should be using AddRecLoop which we have saved and against which
all gate checks are made, and not calling AddRec->getLoop() over and over
again because AddRec may change and become an AddRecurrency from outer loop
during the transform iterations.

Considering this change trivial, commiting for postcommit review.

llvm-svn: 352451

llvm-svn: 352450

This is breaking some of builders, disable modules until it's resolved.

llvm-svn: 352449

Previously, the warning messages might be issued within a wrong test case.

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

llvm-svn: 352447