repository (the same content as those in llvm/ and clang/).

llvm-svn: 352516

We should choose one of these as canonical:

  %z = zext i1 %cmp to i32
  %r = sub i32 %x, %z
  =>
  %s = sext i1 %cmp to i32
  %r = add i32 %x, %s

The test comments assume that the zext form is better,
but we can adjust that if we decide to go the other way.

llvm-svn: 352515

This fixes most references to the paths:
 llvm.org/svn/
 llvm.org/git/
 llvm.org/viewvc/
 github.com/llvm-mirror/
 github.com/llvm-project/
 reviews.llvm.org/diffusion/

to instead point to https://github.com/llvm/llvm-project.

This is *not* a trivial substitution, because additionally, all the
checkout instructions had to be migrated to instruct users on how to
use the monorepo layout, setting LLVM_ENABLE_PROJECTS instead of
checking out various projects into various subdirectories.

I've attempted to not change any scripts here, only documentation. The
scripts will have to be addressed separately.

Additionally, I've deleted one document which appeared to be outdated
and unneeded:
  lldb/docs/building-with-debug-llvm.txt

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

llvm-svn: 352514

llvm-svn: 352513

Mark some of the behavior in the move w/allocator constructors of deque/unordered containers as 'libc++-specific'. Thanks to Andrey Maksimov for pointing this out.

llvm-svn: 352512

llvm-svn: 352511

For failures see:
http://lab.llvm.org:8011/builders/clang-x86_64-linux-abi-test/builds/38501/steps/build-unified-tree/logs/stdio

llvm-svn: 352510

Summary:
This looks like a useful user-facing configuration parameter,
which should be discoverable.

Also fix a small typo in the description.

Reviewers: hokein

Reviewed By: hokein

Subscribers: ioeric, MaskRay, jkorous, arphaman, kadircet, cfe-commits

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

llvm-svn: 352509

References between associated comdats are invalid per COFF spec, but the newest
Windows SDK contains obj files that have these references
(https://bugs.chromium.org/p/chromium/issues/detail?id=925943#c13). So add back
support for them and add tests for them. The old code handled them fine.

This makes lld-link match the behavior of newer link.exe versions as far as I
can tell. (The behavior before this change matched the behavior of older
link.exe versions.)

This mostly reverts r352254.

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

llvm-svn: 352508

The two records aren't used by anything yet, but this part can be
separated out easily, so I am comitting it separately to simplify
reviews of the followup patch.

llvm-svn: 352507

llvm-svn: 352506

Summary:
--set-section-flags is used to change the section flags (e.g. SHF_ALLOC) for given sections. The flags allowed are the same from the existing --rename-section=.old=.new[,flags] feature.

Additionally, make sure that --set-section-flag cannot be used with --rename-section (either the source or destination), since --rename-section accepts flags. This avoids ambiguity for something like "--rename-section=.foo=.bar,alloc --set-section-flag=.bar,code".

Reviewers: jhenderson, jakehehrlich, alexshap, espindola

Reviewed By: jhenderson, jakehehrlich

Subscribers: llvm-commits, emaste, arichardson

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

llvm-svn: 352505

llvm-svn: 352504

Reviewers: ilya-biryukov

Subscribers: cfe-commits

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

llvm-svn: 352503

llvm-svn: 352502

This should have been part of r352494, which added the corresponding
function. The unit test ended up as a separate commit accidentally.

llvm-svn: 352501

I found a really strange WWM issue through a very convoluted shader that
essentially boils down to a bug in SIInstrInfo where canReadVGPR did not
correctly identify that WWM is like a copy and can have a VGPR as its
source.

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

llvm-svn: 352500

llvm-svn: 352499

Summary:
The code tweaks are an implementation of mini-refactorings exposed
via the LSP code actions. They run in two stages:
  - Stage 1. Decides whether the action is available to the user and
    collects all the information required to finish the action.
    Should be cheap, since this will run over all the actions known to
    clangd on each textDocument/codeAction request from the client.

  - Stage 2. Uses information from stage 1 to produce the actual edits
    that the code action should perform. This stage can be expensive and
    will only run if the user chooses to perform the specified action in
    the UI.

One unfortunate consequence of this change is increased latency of
processing the textDocument/codeAction requests, which now wait for an
AST. However, we cannot avoid this with what we have available in the LSP
today.

Reviewers: kadircet, ioeric, hokein, sammccall

Reviewed By: sammccall

Subscribers: mgrang, mgorny, MaskRay, jkorous, arphaman, cfe-commits

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

llvm-svn: 352494

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