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

There is no particular reason why it's not supported, and it is useful.

Differential Revision: https://reviews.llvm.org/D143257
Reviewed By: fhahn

tensor with dims of size 0 cannot be vectorized. Add precondition to
prevent a crash in vectorization.

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

Close https://github.com/llvm/llvm-project/issues/60488.

Previously, when we instantiate a template, the argument dependent
lookup is performed in the context of the instantiation, which implies that the
functions not visible in the context can't be found by the argument
dependent lookup.

But this is not true, according to [module.context]p3, the instantiation
context for the implicit instantiation of a template should contain the
context of the primary module interface if the template is defined in
the module interface unit.

Note that the fix didn't implemnet [module.context]p3 precisely, see the
comments for example.

Reviewed By: rriddle

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

I guess its only reason to exist is potential CT optimization, otherwise it is
just creating cohesion between this code and rewriter internals. We plan to
extend the rewriter. I'd rather not have this cohesion, unless there is a serious
reason to have it.

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

For 4 byte instructions we were always setting size to 4 eventually. Same
for 2 byte instructions. So do it as soon as we know the from the opcode.

Add a return to the end of the 4 byte code so we don't have to have an else
around the 2 byte code.

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

Those ones are extremely mechanical and since that's not libc++ code
in the first place, there's even more of an incentive to do the rename.

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

When we use llc or lld to compiler IR files, the features +nan2008 and +fpxx/+fp64 are not used.
Thus wrong format files are produced.

In IR files, the attributes are only set for function while not the whole compile units.
So we extract the attributes from the first function and use it for the whole unit.

isFPXXDefault: for o32, the FPXX should always be the default, no matter about the vendors.
Of course some distributions with FP64 default enabled should be listed explicit.
Let's add them in future if we know about one.

Reviewed By: MaskRay

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

Address more Destructive type according the review on D141471

* DestructiveUnaryPassthru and DestructiveBinaryImm always return true, don't need fix
* DestructiveTernaryCommWithRev may also return false, but now don't define FalseLanesZero in the backend codegen

Reviewed By: paulwalker-arm

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

Replace unary instructions where the destructive operand is a vector of zeros
with a bundled MOVPRFX instruction, e.g:
       Transform:
           %X0 = DUP_ZI_S 0, 0
           %X0 = FLOGB_ZPmZ_S X0, P0, X2
        into:
            X0 = MOVPRFX P0/z, X1  // doesn't introduce any fake register dependencies compare to X0 = MOVPRFX P0/z, X0
            X0 = FLOGB_ZPmZ_S X0, P0, X2
NOTE: This patch add a @earlyclobber constraint to PredOneOpPassthruPseudo to ensure
    safe register allocation for movprfx usage.

Depends on D105889

Reviewed By: paulwalker-arm

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

This reverts commit 28bd84f5 because
`CodeGen/RISCV/rvv-intrinsics-handcrafted/vlenb.c` hasn't been updated.

This is necessary now that the Docker images don't contain unversionned
clang binaries.

Reject stripped binaries as a policy.

The core issue with stripped binaries is that we can't detect the presence
of split functions which require extra handling. Therefore BOLT can't ensure
functional correctness of produced binary if the input stripped binary contains
split functions. Supporting such cases is an interesting problem but it goes
against BOLT's intended goal of achieving peak program performance.

Reviewed By: maksfb

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

Follow LLVM Coding Standards guideline on using anonymous namespaces
(https://llvm.org/docs/CodingStandards.html#anonymous-namespaces)
and use `static` modifier for function definitions.

Reviewed By: #bolt, maksfb

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

Reviewed By: wrengr

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

Add omitted transform operations, including Affine/MemRef/Vector, to Transform dialect's doc to fix a broken side-bar doc.

Reviewed By: jpienaar

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

Previously we only allowed the flattened list passed in, but the same
input provided here as to buildGeneric so flatten accordingly. We have
less info here than in buildGeneric so the error is more generic if
unpacking fails.

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

Add some missed polish from https://reviews.llvm.org/D143355.

Reviewed By: jrtc27

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

This should keep it consistent with LSAN and ASAN,

Reviewed By: vitalybuka, MaskRay

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

Reviewed By: jhuber6

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

This patch should address a bug when a user have multiple scripted
processes in the same debugging session.

In order for the scripted process plugin to be able to call into the
scripted object instance methods to fetch the necessary data to
reconstruct its state, the scripted process plugin calls into a
scripted process interface, that has a reference to the created script
object instance.

However, prior to this patch, we only had a single instance of the
scripted process interface, living the script interpreter. So every time
a new scripted process plugin was created, it would overwrite the script
object instance that was held by the single scripted process interface
in the script interpreter.

That would cause all the method calls made to the scripted process
interface to be dispatched by the last instanciated script object
instance, which is wrong.

In order to prevent that, this patch moves the scripted process
interface reference to be help by the scripted process plugin itself.

rdar://104882562

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



Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>

This should keep it consistent with LSAN and ASAN,

Reviewed By: vitalybuka, MaskRay

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

[HWASAN] Fix Metadata::IsAllocatedMetadata::IsAllocated to return true even if the requested size is 0.

Reviewed By: MaskRay

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

Authored By: joshua-arch1 (Jun Sha)
Reviewed By: shiva0217, apazos, luismarques, asb, jrtc27, MaskRay
Reviewers: MaskRay, jrtc27

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



This patch is to fix an issue about module linking with LTO.

When compiling with PIE, the small data limitation needs to be consistent with that in PIC, otherwise there will be linking errors due to conflicting values.

bar.c

int bar() { return 1; }
foo.c

int foo() { return 1; }
clang --target=riscv64-unknown-linux-gnu -flto -c foo.c -o foo.o -fPIE
clang --target=riscv64-unknown-linux-gnu -flto -c bar.c -o bar.o -fPIC

clang --target=riscv64-unknown-linux-gnu -flto foo.o bar.o -flto -nostdlib -v -fuse-ld=lld
ld.lld: error: linking module flags 'SmallDataLimit': IDs have conflicting values in 'bar.o' and 'ld-temp.o'
clang-15: error: linker command failed with exit code 1 (use -v to see invocation)
What we are trying to do here is to use Min instead of Error for conflicting SmallDataLimit when combining -fno-PIC code with -fPIC code.

Signed-off-by: xiaojing.zhang <xiaojing.zhang@xcalibyte.com>
Signed-off-by: jianxin.lai <jianxin.lai@xcalibyte.com>

Widen element types of vector arguments of G_ADD, G_SUB, G_MUL, G_AND,
G_OR, G_XOR to the minumum supported size, in order to support vectors
of narrow types.

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

This reverts commit f9ff4988.
Accidentally landed a draft patch.

This patch provides initial support of building Clang runtimes for
Windows when using Fuchsia Clang toolchains under Linux.

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

WIP

There is a failure where we somehow get an invalid register
number being used to calculate the canonical frame address,
and this ends up with lldb crashing with a null deref because it
assumes that it is always able to find information about that
register.

This patch adds a check for a failure to get a register, and
declares the frame invalid in that case, with some additional
logging or an assert for debug builds.

Differential Revision: https://reviews.llvm.org/D143232
rdar://104428038

This reverts commit 254e2ad8.
It contains broken test.

VarArgSystemZHelper.visitCallBase() checks whether the callee has the
"use-soft-float" attribute, but if the callee is a function pointer, a
null pointer dereference happens.

Fix by checking this attribute on the current function. Alternatively,
one could try the callee first, but this is pointless, since one should
not be mixing hardfloat and softfloat code anyway.

Reviewed By: uweigand

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