uabelho (Mikael Holmén)
User

Projects

User does not belong to any projects.

User Details

User Since: Dec 3 2015, 1:10 AM (344 w, 5 h)

Recent Activity
View All

Mon, Jun 13

uabelho added a comment to D125990: [LSR] Fix bug for optimizing unused IVs to final values.

Verified that the current patch also solves the problem I saw.
Thanks!

Mon, Jun 13, 5:57 AM · Restricted Project, Restricted Project

uabelho accepted D127630: [MC] Fix likely uninitialized memory bug.

As I haven't been able to reproduce the problem manually myself I can't confirm that this fixes the problem, but it does seem likely.
Thanks!

Mon, Jun 13, 4:09 AM · Restricted Project, Restricted Project

uabelho added inline comments to D122258: [MC] Omit DWARF unwind info if compact unwind is present where eligible.

Mon, Jun 13, 3:52 AM · Restricted Project, Restricted Project, Restricted Project, Restricted Project

uabelho added a comment to D122258: [MC] Omit DWARF unwind info if compact unwind is present where eligible.

I noticed that on one of our downstream (not public) buildbots the

Mon, Jun 13, 12:46 AM · Restricted Project, Restricted Project, Restricted Project, Restricted Project

Thu, Jun 9

uabelho added inline comments to D126536: [pseudo] Add grammar annotations support..

Thu, Jun 9, 5:30 AM · Restricted Project, Restricted Project

uabelho added inline comments to D126536: [pseudo] Add grammar annotations support..

Thu, Jun 9, 4:46 AM · Restricted Project, Restricted Project

uabelho added a comment to D124561: [lld-macho] Support EH frames under arm64.

When I run tests (check-all) on this commit I get the follwoing two failures:

Thu, Jun 9, 12:24 AM · Restricted Project, Restricted Project, Restricted Project

Jun 7 2022

Herald added a project to D113289: LICM: Hoist LOAD without STORE: Restricted Project.

I wrote an issue about LICM behaving differently with/without debug information with this patch:
https://github.com/llvm/llvm-project/issues/55915

Jun 7 2022, 5:09 AM · Restricted Project, Restricted Project

Jun 3 2022

uabelho added a comment to D126952: [DAGCombiner] Remove overzealous assertion when folding assert+trunc+assert (PR55846).

Fixes https://github.com/llvm/llvm-project/issues/55848 as well.

Jun 3 2022, 3:12 AM · Restricted Project, Restricted Project

Jun 2 2022

uabelho added a comment to D126689: [IR] Enable opaque pointers by default.

In D126689#3553292, @nikic wrote:
@uabelho Here's a slightly cleaned up test case that does not use opaque pointers:
target triple = "x86_64-unknown-linux-gnu"

define void @test(i1 %cond, <1 x i16>* %p) {
  br label %loop

loop:
  %v = load <1 x i16>, <1 x i16>* %p, align 2
  %ins = insertelement <4 x double> zeroinitializer, double 0.000000e+00, i32 0
  %cmp = fcmp uge <4 x double> %ins, zeroinitializer
  %ashr = ashr <1 x i16> %v, %v
  %shuf = shufflevector <4 x i1> %cmp, <4 x i1> zeroinitializer, <4 x i32> zeroinitializer
  br i1 %cond, label %loop, label %exit

exit:
  %use1 = add <4 x i1> %shuf, zeroinitializer
  %use2 = add <1 x i16> %ashr, zeroinitializer
  ret void
}
llvm-stress can probably generate certain code patterns when opaque pointers are enabled, which it does not produce when typed pointers are used. In this case at least, the used pointer type doesn't matter in the end.

Jun 2 2022, 10:51 PM · Restricted Project, Restricted Project, Restricted Project, Restricted Project

uabelho added a comment to D126689: [IR] Enable opaque pointers by default.

Is anyone here ever using llvm-stress?
I noticed that with this patch, llvm-stress seems to start producing code that llc crashes on, and it crashes even if I run on older llc versions.
One example:

llc -o /dev/null stress.ll

crashes with

llc: ../lib/CodeGen/SelectionDAG/SelectionDAG.cpp:5974: llvm::SDValue llvm::SelectionDAG::getNode(unsigned int, const llvm::SDLoc &, llvm::EVT, llvm::SDValue, llvm::SDValue, const llvm::SDNodeFlags): Assertion `VT.isInteger() && N2.getValueType().isInteger() && "Shifts only work on integers"' failed.

Or is the X86 backend just not up to date with opaque pointers yet?

stress.ll997 BDownload

Jun 2 2022, 6:53 AM · Restricted Project, Restricted Project, Restricted Project, Restricted Project

uabelho committed rG35f0890c4edc: [clang-tidy] Remove extra ";" in ModernizeModuleTest.cpp (authored by uabelho).

[clang-tidy] Remove extra ";" in ModernizeModuleTest.cpp

Jun 2 2022, 3:50 AM · Restricted Project, Restricted Project

Jun 1 2022

uabelho added a comment to D126198: [analyzer][NFCi] Annotate major nonnull returning functions.

@steakhal : Thanks for the quick fix!

Jun 1 2022, 10:27 PM · Restricted Project, Restricted Project

uabelho added a comment to D126198: [analyzer][NFCi] Annotate major nonnull returning functions.

In D126198#3549790, @uabelho wrote:
Hi,

I see crashes like this with this patch:
clang: ../../clang/include/clang/StaticAnalyzer/Core/PathSensitive/BasicValueFactory.h:94: clang::ento::PointerToMemberData::PointerToMemberData(const clang::NamedDecl *, llvm::ImmutableList<const CXXBaseSpecifier *>): Assertion `D' failed.
Anyhting known or familiar?

Unfortunately I don't have any reproducer to share (yet).

Jun 1 2022, 4:46 AM · Restricted Project, Restricted Project

uabelho added a comment to D126198: [analyzer][NFCi] Annotate major nonnull returning functions.

I see crashes like this with this patch:

Jun 1 2022, 4:04 AM · Restricted Project, Restricted Project

May 31 2022

uabelho added a comment to D125990: [LSR] Fix bug for optimizing unused IVs to final values.

I've verified that the updated fix also solves the problem I saw.
Thanks!

May 31 2022, 11:49 PM · Restricted Project, Restricted Project

May 30 2022

uabelho added a comment to D123674: Clang-Repl Error Recovery Bug Fix.

I noticed that the testcase Interpreter/execute.cpp starts failing with this patch when run/compiled with asan:

Failed Tests (1):
  Clang :: Interpreter/execute.cpp

Seen in the buildbot run
https://lab.llvm.org/buildbot/#/builders/5/builds/24221

May 30 2022, 11:20 PM · Restricted Project, Restricted Project

May 20 2022

uabelho edited reviewers for D125990: [LSR] Fix bug for optimizing unused IVs to final values, added: Whitney; removed: uabelho.

Thanks! I have confirmed this patch solves the crash I saw.

May 20 2022, 12:22 AM · Restricted Project, Restricted Project

May 18 2022

Herald added a project to D114887: [Analyzer][solver] Simplification: Do a fixpoint iteration before the eq class merge: Restricted Project.

I wrote an issue about a crash with this patch:
https://github.com/llvm/llvm-project/issues/55546

May 18 2022, 12:17 AM · Restricted Project, Restricted Project

May 17 2022

uabelho added a comment to D118808: Loop Strength Reduce - Optimize unused IVs to final values in the exit block with SCEV.

The following starts crashing with this patch:

llc -O1 -o /dev/null bbi-69670_x86.ll

I get:

llc: ../lib/Transforms/Utils/LoopUtils.cpp:1385: int llvm::rewriteLoopExitValues(llvm::Loop *, llvm::LoopInfo *, llvm::TargetLibraryInfo *, llvm::ScalarEvolution *, const llvm::TargetTransformInfo *, llvm::SCEVExpander &, llvm::DominatorTree *, llvm::ReplaceExitVal, SmallVector<llvm::WeakTrackingVH, 16> &): Assertion `EVL->contains(L) && "LCSSA breach detected!"' failed.
PLEASE submit a bug report to https://github.com/llvm/llvm-project/issues/ and include the crash backtrace.
Stack dump:
0.	Program arguments: ../../main-github/llvm/build-all/bin/llc -O1 -o /dev/null bbi-69670_x86.ll
1.	Running pass 'Function Pass Manager' on module 'bbi-69670_x86.ll'.
2.	Running pass 'Loop Pass Manager' on function '@func_1'
3.	Running pass 'Loop Strength Reduction' on basic block '%for.cond6418'
 #0 0x0000000002abded3 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) (../../main-github/llvm/build-all/bin/llc+0x2abded3)
 #1 0x0000000002abbb4e llvm::sys::RunSignalHandlers() (../../main-github/llvm/build-all/bin/llc+0x2abbb4e)
 #2 0x0000000002abe256 SignalHandler(int) Signals.cpp:0:0
 #3 0x00007fcb1f00e630 __restore_rt sigaction.c:0:0
 #4 0x00007fcb1c755387 raise (/lib64/libc.so.6+0x36387)
 #5 0x00007fcb1c756a78 abort (/lib64/libc.so.6+0x37a78)
 #6 0x00007fcb1c74e1a6 __assert_fail_base (/lib64/libc.so.6+0x2f1a6)
 #7 0x00007fcb1c74e252 (/lib64/libc.so.6+0x2f252)
 #8 0x0000000002b80be3 llvm::rewriteLoopExitValues(llvm::Loop*, llvm::LoopInfo*, llvm::TargetLibraryInfo*, llvm::ScalarEvolution*, llvm::TargetTransformInfo const*, llvm::SCEVExpander&, llvm::DominatorTree*, llvm::ReplaceExitVal, llvm::SmallVector<llvm::WeakTrackingVH, 16u>&) (../../main-github/llvm/build-all/bin/llc+0x2b80be3)
 #9 0x00000000024c0a1e ReduceLoopStrength(llvm::Loop*, llvm::IVUsers&, llvm::ScalarEvolution&, llvm::DominatorTree&, llvm::LoopInfo&, llvm::TargetTransformInfo const&, llvm::AssumptionCache&, llvm::TargetLibraryInfo&, llvm::MemorySSA*) LoopStrengthReduce.cpp:0:0
#10 0x00000000024ec121 (anonymous namespace)::LoopStrengthReduce::runOnLoop(llvm::Loop*, llvm::LPPassManager&) LoopStrengthReduce.cpp:0:0
#11 0x0000000001b2d17b llvm::LPPassManager::runOnFunction(llvm::Function&) (../../main-github/llvm/build-all/bin/llc+0x1b2d17b)
#12 0x000000000230895f llvm::FPPassManager::runOnFunction(llvm::Function&) (../../main-github/llvm/build-all/bin/llc+0x230895f)
#13 0x000000000230f398 llvm::FPPassManager::runOnModule(llvm::Module&) (../../main-github/llvm/build-all/bin/llc+0x230f398)
#14 0x0000000002308f2d llvm::legacy::PassManagerImpl::run(llvm::Module&) (../../main-github/llvm/build-all/bin/llc+0x2308f2d)
#15 0x000000000074a073 main (../../main-github/llvm/build-all/bin/llc+0x74a073)
#16 0x00007fcb1c741555 __libc_start_main (/lib64/libc.so.6+0x22555)
#17 0x0000000000747670 _start (../../main-github/llvm/build-all/bin/llc+0x747670)
Abort

May 17 2022, 4:04 AM · Restricted Project, Restricted Project, Restricted Project

uabelho added a comment to D124526: [SimpleLoopUnswitch] Collect either logical ANDs/ORs but not both..

I wrote
https://github.com/llvm/llvm-project/issues/55526
about a crash happening after this was recommited again in 41e142fdc7

May 17 2022, 2:33 AM · Restricted Project, Restricted Project

May 13 2022

uabelho added a comment to D122734: [CUDA][HIP] Fix mangling number for local struct.

In D122734#3509187, @yaxunl wrote:

In D122734#3509096, @yaxunl wrote:

In D122734#3508294, @uabelho wrote:

Hi,

I noticed when compiling with gcc 9.3.0 that we get a bunch of new warnings with this patch:

[1/351] Building CXX object tools/clang/lib/AST/CMakeFiles/obj.clangAST.dir/MicrosoftCXXABI.cpp.o
../../clang/lib/AST/MicrosoftCXXABI.cpp:57:12: warning: 'virtual unsigned int {anonymous}::MicrosoftNumberingContext::getManglingNumber(const clang::VarDecl*, unsigned int)' was hidden [-Woverloaded-virtual]
   57 |   unsigned getManglingNumber(const VarDecl *VD,
      |            ^~~~~~~~~~~~~~~~~
../../clang/lib/AST/MicrosoftCXXABI.cpp:80:12: warning:   by 'virtual unsigned int {anonymous}::MSHIPNumberingContext::getManglingNumber(const clang::TagDecl*, unsigned int)' [-Woverloaded-virtual]
   80 |   unsigned getManglingNumber(const TagDecl *TD,
      |            ^~~~~~~~~~~~~~~~~

fixed by 0f292141aadb0489231de31de966c239486e019d

May 13 2022, 1:00 AM · Restricted Project, Restricted Project

uabelho added a comment to D123901: [LLVM][Casting.h] Update dyn_cast machinery to provide more control over how the casting is performed..

In D123901#3509525, @bzcheeseman wrote:

https://reviews.llvm.org/D125482 doesn't exhibit the problem in the unit test, but now I have to wait for all the other tests to complete so hopefully nothing else breaks!

May 13 2022, 12:57 AM · Restricted Project, Restricted Project

May 12 2022

uabelho added a comment to D122734: [CUDA][HIP] Fix mangling number for local struct.

I noticed when compiling with gcc 9.3.0 that we get a bunch of new warnings with this patch:

[1/351] Building CXX object tools/clang/lib/AST/CMakeFiles/obj.clangAST.dir/MicrosoftCXXABI.cpp.o
../../clang/lib/AST/MicrosoftCXXABI.cpp:57:12: warning: 'virtual unsigned int {anonymous}::MicrosoftNumberingContext::getManglingNumber(const clang::VarDecl*, unsigned int)' was hidden [-Woverloaded-virtual]
   57 |   unsigned getManglingNumber(const VarDecl *VD,
      |            ^~~~~~~~~~~~~~~~~
../../clang/lib/AST/MicrosoftCXXABI.cpp:80:12: warning:   by 'virtual unsigned int {anonymous}::MSHIPNumberingContext::getManglingNumber(const clang::TagDecl*, unsigned int)' [-Woverloaded-virtual]
   80 |   unsigned getManglingNumber(const TagDecl *TD,
      |            ^~~~~~~~~~~~~~~~~
../../clang/lib/AST/MicrosoftCXXABI.cpp:46:12: warning: 'virtual unsigned int {anonymous}::MicrosoftNumberingContext::getManglingNumber(const clang::BlockDecl*)' was hidden [-Woverloaded-virtual]
   46 |   unsigned getManglingNumber(const BlockDecl *BD) override {
      |            ^~~~~~~~~~~~~~~~~
../../clang/lib/AST/MicrosoftCXXABI.cpp:80:12: warning:   by 'virtual unsigned int {anonymous}::MSHIPNumberingContext::getManglingNumber(const clang::TagDecl*, unsigned int)' [-Woverloaded-virtual]
   80 |   unsigned getManglingNumber(const TagDecl *TD,
      |            ^~~~~~~~~~~~~~~~~
../../clang/lib/AST/MicrosoftCXXABI.cpp:42:12: warning: 'virtual unsigned int {anonymous}::MicrosoftNumberingContext::getManglingNumber(const clang::CXXMethodDecl*)' was hidden [-Woverloaded-virtual]
   42 |   unsigned getManglingNumber(const CXXMethodDecl *CallOperator) override {
      |            ^~~~~~~~~~~~~~~~~
../../clang/lib/AST/MicrosoftCXXABI.cpp:80:12: warning:   by 'virtual unsigned int {anonymous}::MSHIPNumberingContext::getManglingNumber(const clang::TagDecl*, unsigned int)' [-Woverloaded-virtual]
   80 |   unsigned getManglingNumber(const TagDecl *TD,
      |            ^~~~~~~~~~~~~~~~~

No idea if it's important or if gcc is overly picky.

May 12 2022, 1:10 AM · Restricted Project, Restricted Project

May 11 2022

uabelho added a comment to D123901: [LLVM][Casting.h] Update dyn_cast machinery to provide more control over how the casting is performed..

Did you notice this:

FAILED: unittests/Support/CMakeFiles/SupportTests.dir/Casting.cpp.o 
/home/buildbots/clang.11.0.0/bin/clang++ --gcc-toolchain=/opt/rh/devtoolset-7/root/usr  -DGTEST_HAS_RTTI=0 -D_DEBUG -D_GNU_SOURCE -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -Iunittests/Support -I/home/buildbots/docker-RHEL-buildbot/SetupBot/worker_env/ppc64le-clang-rhel-test/clang-ppc64le-rhel/llvm-project/llvm/unittests/Support -Iinclude -I/home/buildbots/docker-RHEL-buildbot/SetupBot/worker_env/ppc64le-clang-rhel-test/clang-ppc64le-rhel/llvm-project/llvm/include -I/home/buildbots/docker-RHEL-buildbot/SetupBot/worker_env/ppc64le-clang-rhel-test/clang-ppc64le-rhel/llvm-project/llvm/utils/unittest/googletest/include -I/home/buildbots/docker-RHEL-buildbot/SetupBot/worker_env/ppc64le-clang-rhel-test/clang-ppc64le-rhel/llvm-project/llvm/utils/unittest/googlemock/include -fPIC -fvisibility-inlines-hidden -Werror -Werror=date-time -Werror=unguarded-availability-new -Wall -Wextra -Wno-unused-parameter -Wwrite-strings -Wcast-qual -Wmissing-field-initializers -pedantic -Wno-long-long -Wc++98-compat-extra-semi -Wimplicit-fallthrough -Wcovered-switch-default -Wno-noexcept-type -Wnon-virtual-dtor -Wdelete-non-virtual-dtor -Wsuggest-override -Wstring-conversion -Wmisleading-indentation -fdiagnostics-color -ffunction-sections -fdata-sections -O3 -DNDEBUG    -Wno-variadic-macros -Wno-gnu-zero-variadic-macro-arguments -fno-exceptions -fno-rtti -UNDEBUG -Wno-suggest-override -std=c++14 -MD -MT unittests/Support/CMakeFiles/SupportTests.dir/Casting.cpp.o -MF unittests/Support/CMakeFiles/SupportTests.dir/Casting.cpp.o.d -o unittests/Support/CMakeFiles/SupportTests.dir/Casting.cpp.o -c /home/buildbots/docker-RHEL-buildbot/SetupBot/worker_env/ppc64le-clang-rhel-test/clang-ppc64le-rhel/llvm-project/llvm/unittests/Support/Casting.cpp
In file included from /home/buildbots/docker-RHEL-buildbot/SetupBot/worker_env/ppc64le-clang-rhel-test/clang-ppc64le-rhel/llvm-project/llvm/unittests/Support/Casting.cpp:9:
/home/buildbots/docker-RHEL-buildbot/SetupBot/worker_env/ppc64le-clang-rhel-test/clang-ppc64le-rhel/llvm-project/llvm/include/llvm/Support/Casting.h:216:12: error: returning reference to local temporary object [-Werror,-Wreturn-stack-address]
    return Res2;
           ^~~~
/home/buildbots/docker-RHEL-buildbot/SetupBot/worker_env/ppc64le-clang-rhel-test/clang-ppc64le-rhel/llvm-project/llvm/include/llvm/Support/Casting.h:453:72: note: in instantiation of member function 'llvm::cast_convert_val<llvm::foo, const llvm::bar, const llvm::bar>::doit' requested here
                            typename simplify_type<From>::SimpleType>::doit(f);
                                                                       ^
/home/buildbots/docker-RHEL-buildbot/SetupBot/worker_env/ppc64le-clang-rhel-test/clang-ppc64le-rhel/llvm-project/llvm/include/llvm/Support/Casting.h:564:36: note: in instantiation of member function 'llvm::CastInfo<llvm::foo, const llvm::bar, void>::doCast' requested here
  return CastInfo<To, const From>::doCast(Val);
                                   ^
/home/buildbots/docker-RHEL-buildbot/SetupBot/worker_env/ppc64le-clang-rhel-test/clang-ppc64le-rhel/llvm-project/llvm/include/llvm/Support/Casting.h:214:47: note: binding reference variable 'Res2' here
    typename cast_retty<To, FromTy>::ret_type Res2 =
                                              ^
1 error generated.

from
https://lab.llvm.org/buildbot/#/builders/57/builds/17829/steps/6/logs/stdio

May 11 2022, 11:15 PM · Restricted Project, Restricted Project

uabelho added a comment to D124552: CodeGenPrepare: Replace constant PHI arguments with switch condition value.

In D124552#3506465, @MatzeB wrote:

The following starts hanging in Codegen Prepare with this patch:

Thanks for the report, I fixed this in https://github.com/llvm/llvm-project/commit/de9ad98d2d6358e6aa773f0bb5258b629bde9389

May 11 2022, 10:49 PM · Restricted Project, Restricted Project

uabelho added a comment to D124552: CodeGenPrepare: Replace constant PHI arguments with switch condition value.

The following starts hanging in Codegen Prepare with this patch:

llc -O1 -o /dev/null bbi-69624.ll

May 11 2022, 6:14 AM · Restricted Project, Restricted Project

uabelho added a comment to D124341: [clang-tidy][NFC] Replace many instances of std::string where a StringRef would suffice..

In D124341#3504427, @njames93 wrote:

In D124341#3502659, @uabelho wrote:

Hi,

I noticed that this patch isn't NFC.

Whoops, good catch. I left in some debugging code, fixed in rGa308a55720249749

May 11 2022, 1:23 AM · Restricted Project, Restricted Project

May 10 2022

uabelho added a comment to D124775: [IRSim] Removing check that caused early matching of commutative instructions.

This seems to solve the crash I reported in
https://github.com/llvm/llvm-project/issues/55131

May 10 2022, 12:41 AM · Restricted Project, Restricted Project

May 9 2022

uabelho added a comment to D124341: [clang-tidy][NFC] Replace many instances of std::string where a StringRef would suffice..

I noticed that this patch isn't NFC.

May 9 2022, 11:21 PM · Restricted Project, Restricted Project

uabelho added a comment to D124658: [analyzer] Canonicalize SymIntExpr so the RHS is positive when possible.

In D124658#3500467, @steakhal wrote:

[...]

Could you please give this another shoot at this @uabelho?

May 9 2022, 5:49 AM · Restricted Project, Restricted Project

uabelho added a comment to D124658: [analyzer] Canonicalize SymIntExpr so the RHS is positive when possible.

Not sure if I'm doing something wrong but I can't apply this patch on current top of tree (a4190037fac0)

May 9 2022, 12:51 AM · Restricted Project, Restricted Project

May 8 2022

uabelho added a comment to D123801: [DAG][PowerPC] Combine shuffle(bitcast(X), Mask) to bitcast(shuffle(X, Mask')).

I've stumbled on the (seemingly) infinite execution with this patch as well. I found it with code generated by llvm-stress.
So

llc -march=x86-64 -mcpu=corei7 -o /dev/null foo.ll

hangs in

[2022-05-09 08:43:33.796049513] 0x80f9960     Executing Pass 'X86 DAG->DAG Instruction Selection' on Function 'autogen_SD18620'...

foo.ll18 KBDownload

May 8 2022, 11:47 PM · Restricted Project, Restricted Project

May 6 2022

uabelho added a comment to D124658: [analyzer] Canonicalize SymIntExpr so the RHS is positive when possible.

In D124658#3495973, @steakhal wrote:

This patch triggers a crash with this minimized example.
assertion at L205: "The result operation type must have at least the same number of bits as its operands."
[...]
Please investigate this @tomasz-kaminski-sonarsource

May 6 2022, 1:45 AM · Restricted Project, Restricted Project

Apr 26 2022

uabelho added a comment to D122207: [IROutliner][IRSim] Add all outlined region basic blocks to canonical numbering to add basic blocks to generated PHINode numbering generation..

In D122207#3466709, @uabelho wrote:

Hi!

The following starts to crash with this patch, and it still crashes on current top of tree 036aeac36c:

opt -passes='require<ir-similarity>' -o /dev/null bbi-68950.ll

We get

opt: ../include/llvm/Support/Casting.h:269: typename cast_retty<X, Y *>::ret_type llvm::cast(Y *) [X = llvm::Instruction, Y = llvm::Value]: Assertion `isa<X>(Val) && "cast<Ty>() argument of incompatible type!"' failed.
PLEASE submit a bug report to https://github.com/llvm/llvm-project/issues/ and include the crash backtrace.
Stack dump:
0.	Program arguments: build-all/bin/opt -passes=require<ir-similarity> -o /dev/null /home/uabelho/bbi-68950.ll
Stack dump without symbol names (ensure you have llvm-symbolizer in your PATH or set the environment var `LLVM_SYMBOLIZER_PATH` to point to it):
build-all/bin/opt(_ZN4llvm3sys15PrintStackTraceERNS_11raw_ostreamEi+0x23)[0x2cbf503]
build-all/bin/opt(_ZN4llvm3sys17RunSignalHandlersEv+0xee)[0x2cbd17e]
build-all/bin/opt[0x2cbf886]
/lib64/libpthread.so.0(+0xf630)[0x7f7bebb82630]
/lib64/libc.so.6(gsignal+0x37)[0x7f7be92c9387]
/lib64/libc.so.6(abort+0x148)[0x7f7be92caa78]
/lib64/libc.so.6(+0x2f1a6)[0x7f7be92c21a6]
/lib64/libc.so.6(+0x2f252)[0x7f7be92c2252]
build-all/bin/opt(_ZN4llvm12IRSimilarity21IRSimilarityCandidate27createCanonicalRelationFromERS1_RNS_8DenseMapIjNS_8DenseSetIjNS_12DenseMapInfoIjvEEEES6_NS_6detail12DenseMapPairIjS7_EEEESC_+0x11e6)[0x1b835d6]
build-all/bin/opt(_ZN4llvm12IRSimilarity22IRSimilarityIdentifier14findCandidatesERSt6vectorIPNS0_17IRInstructionDataESaIS4_EERS2_IjSaIjEE+0xa51)[0x1b84631]
build-all/bin/opt(_ZN4llvm12IRSimilarity22IRSimilarityIdentifier14findSimilarityERNS_6ModuleE+0xec)[0x1b854ac]
build-all/bin/opt(_ZN4llvm20IRSimilarityAnalysis3runERNS_6ModuleERNS_15AnalysisManagerIS1_JEEE+0x181)[0x1b85a81]
build-all/bin/opt[0x2fe4320]
build-all/bin/opt(_ZN4llvm15AnalysisManagerINS_6ModuleEJEE13getResultImplEPNS_11AnalysisKeyERS1_+0x20e)[0x245fb1e]
build-all/bin/opt[0x2ff1258]
build-all/bin/opt[0x2ff109d]
build-all/bin/opt(_ZN4llvm11PassManagerINS_6ModuleENS_15AnalysisManagerIS1_JEEEJEE3runERS1_RS3_+0x208)[0x245d3d8]
build-all/bin/opt(_ZN4llvm15runPassPipelineENS_9StringRefERNS_6ModuleEPNS_13TargetMachineEPNS_21TargetLibraryInfoImplEPNS_14ToolOutputFileES8_S8_S0_NS_8ArrayRefIS0_EENS9_INS_10PassPluginEEENS_8opt_tool10OutputKindENSD_12VerifierKindEbbbbb+0x3f9f)[0x78657f]
build-all/bin/opt(main+0x3fad)[0x7972cd]
/lib64/libc.so.6(__libc_start_main+0xf5)[0x7f7be92b5555]
build-all/bin/opt[0x780ec0]

bbi-68950.ll544 BDownload

Apr 26 2022, 10:39 PM · Restricted Project, Restricted Project

Herald added a project to D116969: [IRBuilder] Migrate icmp-folding to value-based FoldICmp.: Restricted Project.

I wrote
https://github.com/llvm/llvm-project/issues/55100
about a crash starting to happen with this patch.

Apr 26 2022, 3:50 AM · Restricted Project, Restricted Project

Apr 22 2022

uabelho added a comment to D122207: [IROutliner][IRSim] Add all outlined region basic blocks to canonical numbering to add basic blocks to generated PHINode numbering generation..

The following starts to crash with this patch, and it still crashes on current top of tree 036aeac36c:

opt -passes='require<ir-similarity>' -o /dev/null bbi-68950.ll

We get

opt: ../include/llvm/Support/Casting.h:269: typename cast_retty<X, Y *>::ret_type llvm::cast(Y *) [X = llvm::Instruction, Y = llvm::Value]: Assertion `isa<X>(Val) && "cast<Ty>() argument of incompatible type!"' failed.
PLEASE submit a bug report to https://github.com/llvm/llvm-project/issues/ and include the crash backtrace.
Stack dump:
0.	Program arguments: build-all/bin/opt -passes=require<ir-similarity> -o /dev/null /home/uabelho/bbi-68950.ll
Stack dump without symbol names (ensure you have llvm-symbolizer in your PATH or set the environment var `LLVM_SYMBOLIZER_PATH` to point to it):
build-all/bin/opt(_ZN4llvm3sys15PrintStackTraceERNS_11raw_ostreamEi+0x23)[0x2cbf503]
build-all/bin/opt(_ZN4llvm3sys17RunSignalHandlersEv+0xee)[0x2cbd17e]
build-all/bin/opt[0x2cbf886]
/lib64/libpthread.so.0(+0xf630)[0x7f7bebb82630]
/lib64/libc.so.6(gsignal+0x37)[0x7f7be92c9387]
/lib64/libc.so.6(abort+0x148)[0x7f7be92caa78]
/lib64/libc.so.6(+0x2f1a6)[0x7f7be92c21a6]
/lib64/libc.so.6(+0x2f252)[0x7f7be92c2252]
build-all/bin/opt(_ZN4llvm12IRSimilarity21IRSimilarityCandidate27createCanonicalRelationFromERS1_RNS_8DenseMapIjNS_8DenseSetIjNS_12DenseMapInfoIjvEEEES6_NS_6detail12DenseMapPairIjS7_EEEESC_+0x11e6)[0x1b835d6]
build-all/bin/opt(_ZN4llvm12IRSimilarity22IRSimilarityIdentifier14findCandidatesERSt6vectorIPNS0_17IRInstructionDataESaIS4_EERS2_IjSaIjEE+0xa51)[0x1b84631]
build-all/bin/opt(_ZN4llvm12IRSimilarity22IRSimilarityIdentifier14findSimilarityERNS_6ModuleE+0xec)[0x1b854ac]
build-all/bin/opt(_ZN4llvm20IRSimilarityAnalysis3runERNS_6ModuleERNS_15AnalysisManagerIS1_JEEE+0x181)[0x1b85a81]
build-all/bin/opt[0x2fe4320]
build-all/bin/opt(_ZN4llvm15AnalysisManagerINS_6ModuleEJEE13getResultImplEPNS_11AnalysisKeyERS1_+0x20e)[0x245fb1e]
build-all/bin/opt[0x2ff1258]
build-all/bin/opt[0x2ff109d]
build-all/bin/opt(_ZN4llvm11PassManagerINS_6ModuleENS_15AnalysisManagerIS1_JEEEJEE3runERS1_RS3_+0x208)[0x245d3d8]
build-all/bin/opt(_ZN4llvm15runPassPipelineENS_9StringRefERNS_6ModuleEPNS_13TargetMachineEPNS_21TargetLibraryInfoImplEPNS_14ToolOutputFileES8_S8_S0_NS_8ArrayRefIS0_EENS9_INS_10PassPluginEEENS_8opt_tool10OutputKindENSD_12VerifierKindEbbbbb+0x3f9f)[0x78657f]
build-all/bin/opt(main+0x3fad)[0x7972cd]
/lib64/libc.so.6(__libc_start_main+0xf5)[0x7f7be92b5555]
build-all/bin/opt[0x780ec0]

Apr 22 2022, 12:21 AM · Restricted Project, Restricted Project

Apr 18 2022

uabelho added a comment to rG43acef48d38e: [JITLink] Refactor and expand DWARF pointer encoding support..

In rG43acef48d38ec0dd391f212144d4a25095e4fc5f#1078194, @lhames wrote:

In rG43acef48d38ec0dd391f212144d4a25095e4fc5f#1078173, @uabelho wrote:

...
Any idea what's wrong?

The test case depends on type-info for int (_ZTIi) since that's what the catch-handlers in the test are catching. If llvm is built without type-info (the default) and your C++ standard library doesn't export _ZTIi then you'll get the missing symbol error that you saw.

We're not actually executing the test code, we're just linking it, so it's sufficient for _ZTIi to resolve to some value. I've added the -phony-externals option in 6db0807c2cbe, which should fix the problem by causing _ZTIi (and any other unresolved externals) to resolve to null.

Apr 18 2022, 12:14 AM · Restricted Project, Restricted Project

Apr 17 2022

uabelho added a comment to rG43acef48d38e: [JITLink] Refactor and expand DWARF pointer encoding support..

The new testcase
ELF_ehframe_large_static_personality_encodings.s
fails for me when I compile and run on a RHEL7 linux machine.
When I run

/repo/uabelho/master-github/llvm/build-all/bin/llvm-jitlink -debug-only=jitlink -noexec /repo/uabelho/master-github/llvm/build-all/test/ExecutionEngine/JITLink/X86/Output/ELF_ehframe_large_static_personality_encodings.s.tmp

I get something that ends with

External symbols:
  0x0: 0x0 (addressable + 0x00000000): size: 0x00000000, linkage: strong, scope: default, live  -   __gxx_personality_v0
  0x0: 0x0 (addressable + 0x00000000): size: 0x00000000, linkage: strong, scope: default, live  -   _GLOBAL_OFFSET_TABLE_
  0x0: 0x0 (addressable + 0x00000000): size: 0x00000000, linkage: strong, scope: default, live  -   __cxa_begin_catch
  0x0: 0x0 (addressable + 0x00000000): size: 0x00000000, linkage: strong, scope: default, live  -   __cxa_end_catch
  0x0: 0x0 (addressable + 0x00000000): size: 0x00000000, linkage: strong, scope: default, live  -   __cxa_throw
  0x0: 0x0 (addressable + 0x00000000): size: 0x00000000, linkage: strong, scope: default, live  -   _ZTIi
  0x0: 0x0 (addressable + 0x00000000): size: 0x00000000, linkage: strong, scope: default, live  -   __cxa_allocate_exception
Resolving symbols defined in /repo/uabelho/master-github/llvm/build-all/test/ExecutionEngine/JITLink/X86/Output/ELF_ehframe_large_static_personality_encodings.s.tmp
Issuing lookup for external symbols for /repo/uabelho/master-github/llvm/build-all/test/ExecutionEngine/JITLink/X86/Output/ELF_ehframe_large_static_personality_encodings.s.tmp (may trigger materialization/linking of other graphs)...
Starting link phase 3 for graph /repo/uabelho/master-github/llvm/build-all/test/ExecutionEngine/JITLink/X86/Output/ELF_ehframe_large_static_personality_encodings.s.tmp
JIT session error: Symbols not found: [ _ZTIi ]
/repo/uabelho/master-github/llvm/build-all/bin/llvm-jitlink: Failed to materialize symbols: { (main, { pe_absptr, main, pe_indir_pcrel_sdata8, DW.ref.__gxx_personality_v0 }) }

Attaching the full output as foo.log.

foo.log29 KBDownload

Apr 17 2022, 12:15 AM · Restricted Project, Restricted Project

Apr 14 2022

uabelho added a comment to D123300: [Clang] Enable opaque pointers by default.

In D123300#3451087, @nikic wrote:

@uabelho The IR is correct, but requires using opt -opaque-pointers explicitly. Normally, opaque pointer mode is automatically enabled, but there is no explicit mention of ptr in the IR. Not sure if we can do anything to improve that before the default on the opt side is switched.

Apr 14 2022, 2:16 AM · Restricted Project, Restricted Project, Restricted Project

uabelho added a comment to D123300: [Clang] Enable opaque pointers by default.

I noticed this produces broken code:
clang -cc1 -triple amdgcn-- -emit-llvm -o - -x c op.c

Apr 14 2022, 1:51 AM · Restricted Project, Restricted Project, Restricted Project

Apr 7 2022

uabelho added a comment to D123270: RegAllocGreedy: Allow last chance recolor to retry overlapping tuples.

This makes sense to me.

Apr 7 2022, 9:26 PM · Restricted Project, Restricted Project

Apr 5 2022

uabelho added inline comments to D122804: [AMDGPU] Only count global-to-global as indirect accesses.

Apr 5 2022, 12:13 AM · Restricted Project, Restricted Project

Apr 4 2022

uabelho added inline comments to D122804: [AMDGPU] Only count global-to-global as indirect accesses.

Apr 4 2022, 9:42 PM · Restricted Project, Restricted Project

Mar 31 2022

uabelho added a comment to D122817: [Float2Int] Make sure dependent ranges are calculated first (PR54669).

Nice! I've verified that this solves the problem I saw.
Thanks!

Mar 31 2022, 10:11 PM · Restricted Project, Restricted Project

Mar 30 2022

uabelho added a comment to D122471: [IR] Require intrinsic struct return type to be anonymous.

In D122471#3416797, @nikic wrote:

@uabelho Can you please check whether https://github.com/llvm/llvm-project/commit/d6887256c2cae1b1b721bd47459be6d86003db6f fixes the problem you're seeing?

Mar 30 2022, 9:34 AM · Restricted Project, Restricted Project, Restricted Project

uabelho added a comment to D122471: [IR] Require intrinsic struct return type to be anonymous.

In D122471#3416528, @uabelho wrote:

Hello,

No idea what is happening yet but I've seen some pretty nasty memory consumption by opt that I bisected to this patch.

Any idea what could be going on?

I'll see if I can see if I can extract some reproducer.

Mar 30 2022, 7:18 AM · Restricted Project, Restricted Project, Restricted Project

uabelho added a comment to D122471: [IR] Require intrinsic struct return type to be anonymous.

No idea what is happening yet but I've seen some pretty nasty memory consumption by opt that I bisected to this patch.

Mar 30 2022, 6:24 AM · Restricted Project, Restricted Project, Restricted Project

uabelho added a comment to D122580: RegAllocGreedy: Roll back successful recolorings on failure.

I've run some tests with this patch over night without problems. We end up in tryLastChanceRecoloring fairly often when running tests on our out-of-tree target so I have probably exercised the new code a bit at least.

Mar 30 2022, 12:57 AM · Restricted Project, Restricted Project

Mar 29 2022

Herald added a project to D120133: [instsimplify] Assume storage for byval args doesn't overlap allocas, globals, or other byval args: Restricted Project.

I wrote
https://github.com/llvm/llvm-project/issues/54615
about a crash that started happening with this patch.

Mar 29 2022, 6:25 AM · Restricted Project, Restricted Project

Mar 28 2022

uabelho added a comment to D122271: [Clang] -Wunused-but-set-variable warning - handle also pre/post unary operators .

I noticed these to warning when compiling libunwind/src/UnwindLevel1.c with this patch:

00:22:48 /repo/bbiswjenk/fem2s10-eiffel176/workspace/llvm/sdk_1_20_ki_dev_test/libunwind/src/UnwindLevel1.c:175:12: warning: variable 'framesWalked' set but not used [-Wunused-but-set-variable]
00:22:48   unsigned framesWalked = 1;
00:22:48            ^
00:22:48 /repo/bbiswjenk/fem2s10-eiffel176/workspace/llvm/sdk_1_20_ki_dev_test/libunwind/src/UnwindLevel1.c:293:12: warning: variable 'framesWalked' set but not used [-Wunused-but-set-variable]
00:22:48   unsigned framesWalked = 1;
00:22:48            ^
00:22:48 2 warnings generated.

Mar 28 2022, 10:07 PM · Restricted Project, Restricted Project

Mar 24 2022

uabelho added a comment to D118538: [SLP] Schedule only sub-graph of vectorizable instructions.

I've run some more testing with this patch reapplied locally without seeing problems so there at least doesn't seem to be anything that pops up at once for us.
(Always hard to know how much testing is "enough" when running fuzz testing though, but I've run tests for two nights without seeing anything else than the problem above that has already been fixed.)

Mar 24 2022, 7:05 AM · Restricted Project, Restricted Project

Mar 21 2022

uabelho added a comment to D118538: [SLP] Schedule only sub-graph of vectorizable instructions.

In D118538#3398720, @uabelho wrote:
Hi,

Heads up that I've seen the following assert (added in 6253b77da) trigger in one of our downstream tests:
opt: ../lib/Transforms/Vectorize/SLPVectorizer.cpp:8066: void llvm::slpvectorizer::BoUpSLP::BlockScheduling::calculateDependencies(llvm::slpvectorizer::BoUpSLP::ScheduleData *, bool, llvm::slpvectorizer::BoUpSLP *): Assertion `DepDest && "must be in schedule window"' failed.
I'll try to extract a reproducer and come back.

Mar 21 2022, 11:44 PM · Restricted Project, Restricted Project

uabelho added a comment to D118538: [SLP] Schedule only sub-graph of vectorizable instructions.

Heads up that I've seen the following assert (added in 6253b77da) trigger in one of our downstream tests:

opt: ../lib/Transforms/Vectorize/SLPVectorizer.cpp:8066: void llvm::slpvectorizer::BoUpSLP::BlockScheduling::calculateDependencies(llvm::slpvectorizer::BoUpSLP::ScheduleData *, bool, llvm::slpvectorizer::BoUpSLP *): Assertion `DepDest && "must be in schedule window"' failed.

I'll try to extract a reproducer and come back.

Mar 21 2022, 11:18 PM · Restricted Project, Restricted Project

uabelho added a comment to D121572: [X86][NFC] Generate mnemonic tables.

In D121572#3396262, @Amir wrote:

In D121572#3396218, @uabelho wrote:

Hello,

I noticed that if compilng with ubsan
-DLLVM_USE_SANITIZER='Undefined'
you get the following error when compiling llc with this patch:

FAILED: lib/Target/X86/X86GenMnemonicTables.inc
cd /repo/uabelho/master-github/llvm/build-all-bbisdk-ubsan && /repo/uabelho/master-github/llvm/build-all-bbisdk-ubsan/bin/llvm-tblgen -gen-x86-mnemonic-tables -asmwriternum=1 -I /repo/uabelho/master-github/llvm/lib/Target/X86 -I/repo/uabelho/master-github/llvm/build-all-bbisdk-ubsan/include -I/repo/uabelho/master-github/llvm/include -I /repo/uabelho/master-github/llvm/lib/Target /repo/uabelho/master-github/llvm/lib/Target/X86/X86.td --write-if-changed -o lib/Target/X86/X86GenMnemonicTables.inc -d lib/Target/X86/X86GenMnemonicTables.inc.d
../utils/TableGen/X86MnemonicTables.cpp:52:29: runtime error: load of value 170, which is not a valid value for type 'bool'
SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior ../utils/TableGen/X86MnemonicTables.cpp:52:29 in

Hello and thanks for reporting! Working on it. Note there's an earlier report here: https://reviews.llvm.org/D121571#3396209

Mar 21 2022, 7:26 AM · Restricted Project, Restricted Project

uabelho added a comment to D121572: [X86][NFC] Generate mnemonic tables.

I noticed that if compilng with ubsan
-DLLVM_USE_SANITIZER='Undefined'
you get the following error when compiling llc with this patch:

Mar 21 2022, 7:16 AM · Restricted Project, Restricted Project

Herald added a project to D119655: [Driver][NetBSD] -r: imply -nostdlib like GCC: Restricted Project.

Mar 21 2022, 6:05 AM · Restricted Project, Restricted Project

uabelho added a comment to D118538: [SLP] Schedule only sub-graph of vectorizable instructions.

In D118538#3359672, @uabelho wrote:

I wrote
https://github.com/llvm/llvm-project/issues/54197
and
https://github.com/llvm/llvm-project/issues/54198
about the two problems I've seen.

Mar 21 2022, 3:27 AM · Restricted Project, Restricted Project

Mar 18 2022

uabelho added a comment to D119973: RegAllocGreedy: Fix last chance recolor assert in impossible case.

In D119973#3360529, @arsenm wrote:

In D119973#3359120, @uabelho wrote:

In D119973#3358798, @arsenm wrote:

I'm beginning to think that mayRecolorAllInterferences has no obligation to skip based on the register class / subregisters, and something else is wrong. The full interference checks are done later. The main failure I'm observing happens when trying to restore the allocation state after last chance recoloring fails. It ends up trying to restore the assignment of a register which is already allocated. I suspect something is going wrong when this is recursively called

Not sure if it's what you are experiencing, but tryLastChanceRecoloring is broken in a few cases where "complicated" things have happened during the "try" part of it.

If recoloring fails, it tries to restore the state, but it does not restore e.g. splitting of vregs that happened.

So e.g. if one of the evicted vregs get splitted, then the allocator may end up in a corrupted state after the physreg is restored to the splitted vreg. The vreg may then have an empty live range but still have a physreg allocated, and this may later lead to a number of different assertions and crashes.

I think this is exactly what's happening

Mar 18 2022, 5:05 AM · Restricted Project, Restricted Project

Mar 17 2022

uabelho added a comment to D119479: [clang][extract-api] Add global record support.

In D119479#3389684, @zixuw wrote:

In D119479#3388498, @uabelho wrote:

Hello,

Did you see this sanitizer error when running global_record.c?

https://lab.llvm.org/buildbot/#/builders/5/builds/20765/steps/13/logs/stdio

Hi @uabelho, I've disabled the test for now in 54b145d5cac2b008380828e8f67c439038ea370b.

Mar 17 2022, 11:43 PM · Restricted Project, Restricted Project

uabelho added a comment to D121678: [pseudo] Split greatergreater token..

It seems like the new testcase fails when run with sanitizers:
https://lab.llvm.org/buildbot/#/builders/5/builds/20833

Mar 17 2022, 11:37 PM · Restricted Project, Restricted Project, Restricted Project

uabelho added a comment to D119479: [clang][extract-api] Add global record support.

Did you see this sanitizer error when running global_record.c?

Mar 17 2022, 1:25 AM · Restricted Project, Restricted Project

Mar 13 2022

uabelho added a comment to D121331: Cleanup include: TableGen.

In D121331#3375170, @serge-sans-paille wrote:

In D121331#3375150, @uabelho wrote:

Hello,

This broke compiling with
-DLLVM_ENABLE_Z3_SOLVER=ON

12:39:06 ../lib/Support/Z3Solver.cpp:42:28: error: 'llvm::Twine' is an incomplete type
12:39:06 llvm::Twine(Z3_get_error_msg(Context, Error)));
12:39:06 ^
12:39:06 ../include/llvm/Support/ErrorHandling.h:21:9: note: forward declaration of 'llvm::Twine'
12:39:06 class Twine;
12:39:06 ^

etc

Thanks for reporting the error. Should be fixed on main now.

Mar 13 2022, 11:06 PM · Restricted Project, Restricted Project

Mar 11 2022

uabelho added a comment to D121331: Cleanup include: TableGen.

This broke compiling with
-DLLVM_ENABLE_Z3_SOLVER=ON

Mar 11 2022, 6:29 AM · Restricted Project, Restricted Project

Mar 8 2022

uabelho added a comment to D120979: [libcxx] [test] Skip the get/put long_double_ru_RU tests on Glibc < 2.27.

In D120979#3368343, @ldionne wrote:

@uabelho Just out of curiosity, what's the system you're running on that has glibc 2.27?

Mar 8 2022, 10:06 PM · Restricted Project, Restricted Project

Mar 6 2022

uabelho added a comment to D120979: [libcxx] [test] Skip the get/put long_double_ru_RU tests on Glibc < 2.27.

I've verified that the current patch solves the problem we see with glibc 2.17

Mar 6 2022, 11:56 PM · Restricted Project, Restricted Project

Mar 4 2022

uabelho added a comment to D118538: [SLP] Schedule only sub-graph of vectorizable instructions.

In D118538#3357833, @reames wrote:

In D118538#3356307, @uabelho wrote:

We see other problems that started appearing with this commit.

If you have known problems, please file a bug. Waiting until I fix one and then reporting something new in the review after a reland is less than helpful.

I'm about to revert again. I don't have time to investigate this immediately, so it'll probably be a day or two before I report back on the cause of this one.

Mar 4 2022, 4:22 AM · Restricted Project, Restricted Project

uabelho added a comment to D120979: [libcxx] [test] Skip the get/put long_double_ru_RU tests on Glibc < 2.27.

In D120979#3359388, @mstorsjo wrote:

In D120979#3359386, @uabelho wrote:

Thanks! The tests pass for me now with glibc 2.17

Great! I'll wait for a libc++ approver still before pushing.

Mar 4 2022, 1:05 AM · Restricted Project, Restricted Project

uabelho accepted D120979: [libcxx] [test] Skip the get/put long_double_ru_RU tests on Glibc < 2.27.

Thanks! The tests pass for me now with glibc 2.17

Mar 4 2022, 1:03 AM · Restricted Project, Restricted Project

uabelho added a comment to D120317: [libcxx] [test] Fix get/put long_double_ru_RU on Glibc, FreeBSD and Windows.

In D120317#3359354, @mstorsjo wrote:

In D120317#3359350, @uabelho wrote:

In D120317#3359332, @mstorsjo wrote:

What glibc version do you have? As you're on RHEL, I would expect an older one (mine is on Ubuntu 20.04, with glibc 2.31). There seems to be differences in most fields, in particular in mon_decimal_point here. We already have some conditionals due to the fact that currency_symbol differs for ru_RU.UTF-8 in various glibc versions (apparently with the new form appearing in 2.24), but we never had any glibc conditionals for the differing mon_decimal_point. As that probably would require quite intrusive changes to the test, I guess it's probably best to make the test bail out on such older versions (as it just has been XFAILed forever on that platform before anyway).

Seems like it 2.17. ldd on the bult binary says e.g.
libc.so.6 => /lib64/libc.so.6 (0x00007fc160eed000)
and then
-> /lib64/libc.so.6
GNU C Library (GNU libc) stable release version 2.17, by Roland McGrath et al.

Thanks!

I dug around and found that this change stems from https://sourceware.org/git/?p=glibc.git;a=commitdiff;h=f11f2f6e145d6fc6b52f6b0733599f8b96595733, and that commit was part of the 2.27 release.

Mar 4 2022, 12:53 AM · Restricted Project, Restricted Project

uabelho added a comment to D120317: [libcxx] [test] Fix get/put long_double_ru_RU on Glibc, FreeBSD and Windows.

In D120317#3359332, @mstorsjo wrote:

What glibc version do you have? As you're on RHEL, I would expect an older one (mine is on Ubuntu 20.04, with glibc 2.31). There seems to be differences in most fields, in particular in mon_decimal_point here. We already have some conditionals due to the fact that currency_symbol differs for ru_RU.UTF-8 in various glibc versions (apparently with the new form appearing in 2.24), but we never had any glibc conditionals for the differing mon_decimal_point. As that probably would require quite intrusive changes to the test, I guess it's probably best to make the test bail out on such older versions (as it just has been XFAILed forever on that platform before anyway).

Mar 4 2022, 12:44 AM · Restricted Project, Restricted Project

uabelho added a comment to D120317: [libcxx] [test] Fix get/put long_double_ru_RU on Glibc, FreeBSD and Windows.

In D120317#3359186, @mstorsjo wrote:

Sorry about that. It would seem like there are differences in the ru_RU.UTF-8 locale in your installation than in the ones used in CI and in my local environment. What glibc version are you running (as it would seem we require to selectively expect different results on different versions of glibc)?

Can you rerun the put_long_double_ru_RU.pass.cpp test with this diff applied?

diff --git a/libcxx/test/std/localization/locale.categories/category.monetary/locale.money.put/locale.money.put.members/put_long_double_ru_RU.pass.cpp b/libcxx/test/std/localization/locale.categories/category.monetary/locale.money.put/locale.money.put.members/put_long_double_ru_RU.pass.cpp
index ae5071907aca..a7156e78132e 100644
--- a/libcxx/test/std/localization/locale.categories/category.monetary/locale.money.put/locale.money.put.members/put_long_double_ru_RU.pass.cpp
+++ b/libcxx/test/std/localization/locale.categories/category.monetary/locale.money.put/locale.money.put.members/put_long_double_ru_RU.pass.cpp
@@ -77,6 +77,9 @@ int main(int, char**)
         char str[100];
         cpp17_output_iterator<char*> iter = f.put(cpp17_output_iterator<char*>(str), false, ios, '*', v);
         std::string ex(str, base(iter));
+        for (char c : ex)
+            fprintf(stderr, "%02x ", c);
+        fprintf(stderr, "\n");                 
         assert(ex == "0,00");
     }      
     {   // negative one

Mar 4 2022, 12:18 AM · Restricted Project, Restricted Project

Mar 3 2022

uabelho added a comment to D120317: [libcxx] [test] Fix get/put long_double_ru_RU on Glibc, FreeBSD and Windows.

I see the following failures with this commit:

FAIL: libc++ :: std/localization/locale.categories/category.monetary/locale.money.get/locale.money.get.members/get_long_double_ru_RU.pass.cpp (466 of 7808)
******************** TEST 'libc++ :: std/localization/locale.categories/category.monetary/locale.money.get/locale.money.get.members/get_long_double_ru_RU.pass.cpp' FAILED ********************
Script:
--
: 'COMPILED WITH';  /repo/uabelho/master-github/llvm/build-all-builtins/./bin/clang++ /repo/uabelho/master-github/libcxx/test/std/localization/locale.categories/category.monetary/locale.money.get/locale.money.get.members/get_long_double_ru_RU.pass.cpp -v --target=x86_64-unknown-linux-gnu -nostdinc++ -isystem /repo/uabelho/master-github/llvm/build-all-builtins/include/x86_64-unknown-linux-gnu/c++/v1 -isystem /repo/uabelho/master-github/llvm/build-all-builtins/include/c++/v1 -I/repo/uabelho/master-github/llvm/build-all-builtins/runtimes/runtimes-x86_64-unknown-linux-gnu-bins/libcxx/include/c++build -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -I/repo/uabelho/master-github/libcxx/test/support -std=c++2b -Werror -Wall -Wextra -Wshadow -Wundef -Wno-unused-command-line-argument -Wno-attributes -Wno-pessimizing-move -Wno-c++11-extensions -Wno-user-defined-literals -Wno-noexcept-type -Wno-atomic-alignment -Wsign-compare -Wunused-variable -Wunused-parameter -Wunreachable-code -Wno-unused-local-typedef -D_LIBCPP_DISABLE_AVAILABILITY -fcoroutines-ts -Werror=thread-safety -Wuser-defined-warnings -D_LIBCPP_HAS_NO_PRAGMA_SYSTEM_HEADER  -lc++experimental -L/repo/uabelho/master-github/llvm/build-all-builtins/./lib/x86_64-unknown-linux-gnu -Wl,-rpath,/repo/uabelho/master-github/llvm/build-all-builtins/./lib/x86_64-unknown-linux-gnu -L/repo/uabelho/master-github/llvm/build-all-builtins/./lib/x86_64-unknown-linux-gnu -Wl,-rpath,/repo/uabelho/master-github/llvm/build-all-builtins/./lib/x86_64-unknown-linux-gnu -nodefaultlibs -lc++ -lm -lgcc_s -lgcc -lpthread -lc -lgcc_s -lgcc -latomic -o /repo/uabelho/master-github/llvm/build-all-builtins/runtimes/runtimes-x86_64-unknown-linux-gnu-bins/libcxx/test/std/localization/locale.categories/category.monetary/locale.money.get/locale.money.get.members/Output/get_long_double_ru_RU.pass.cpp.dir/t.tmp.exe
: 'EXECUTED AS';  "/app/vbuild/RHEL7-x86_64/python/3.8.0/bin/python3.8" /repo/uabelho/master-github/libcxx/test/../utils/run.py --execdir /repo/uabelho/master-github/llvm/build-all-builtins/runtimes/runtimes-x86_64-unknown-linux-gnu-bins/libcxx/test/std/localization/locale.categories/category.monetary/locale.money.get/locale.money.get.members/Output/get_long_double_ru_RU.pass.cpp.dir --codesign_identity "" --env  --  /repo/uabelho/master-github/llvm/build-all-builtins/runtimes/runtimes-x86_64-unknown-linux-gnu-bins/libcxx/test/std/localization/locale.categories/category.monetary/locale.money.get/locale.money.get.members/Output/get_long_double_ru_RU.pass.cpp.dir/t.tmp.exe
--
Exit Code: 250

Mar 3 2022, 10:31 PM · Restricted Project, Restricted Project

uabelho added a comment to D119973: RegAllocGreedy: Fix last chance recolor assert in impossible case.

In D119973#3358798, @arsenm wrote:

I'm beginning to think that mayRecolorAllInterferences has no obligation to skip based on the register class / subregisters, and something else is wrong. The full interference checks are done later. The main failure I'm observing happens when trying to restore the allocation state after last chance recoloring fails. It ends up trying to restore the assignment of a register which is already allocated. I suspect something is going wrong when this is recursively called

Mar 3 2022, 9:46 PM · Restricted Project, Restricted Project

uabelho added a comment to D118538: [SLP] Schedule only sub-graph of vectorizable instructions.

Another somewhat similar case but with less different compiler flags needed:

build-all-builtins/bin/clang -finline-hint-functions -std=c99 -fsanitize=undefined -O2 'vla_sum_1.c' -o 'vla_sum_1.out'
./vla_sum_1.out

Result:

UndefinedBehaviorSanitizer:DEADLYSIGNAL
==160192==ERROR: UndefinedBehaviorSanitizer: BUS on unknown address (pc 0x00000042b6c9 bp 0x7fff7d630950 sp 0x1000100010001 T160192)
==160192==The signal is caused by a READ memory access.
==160192==Hint: this fault was caused by a dereference of a high value address (see register values below).  Disassemble the provided pc to learn which register was used.
    #0 0x42b6c9  (/repo/uabelho/master-github/llvm/vla_sum_1.out+0x42b6c9)
    #1 0x42b857  (/repo/uabelho/master-github/llvm/vla_sum_1.out+0x42b857)
    #2 0x7fa2c69b4554  (/lib64/libc.so.6+0x22554) (BuildId: e6847a931dd483773bab779dd3985b17c11caab2)
    #3 0x402cb4  (/repo/uabelho/master-github/llvm/vla_sum_1.out+0x402cb4)

Mar 3 2022, 12:49 AM · Restricted Project, Restricted Project

uabelho added a comment to D118538: [SLP] Schedule only sub-graph of vectorizable instructions.

We see other problems that started appearing with this commit.
With

build-all-builtins/bin/clang -finline-hint-functions -fstack-protector-all -fwrapv -std=c99 -fsanitize=undefined -O3 'vla_sum_4.c' -fsanitize=undefined -l gcc_s -o 'vla_sum_4.out'
./vla_sum_4.out

we see

*** stack smashing detected ***: ./vla_sum_4.out terminated
======= Backtrace: =========
/lib64/libc.so.6(__fortify_fail+0x37)[0x7fc20889c697]
/lib64/libc.so.6(+0x118652)[0x7fc20889c652]
./vla_sum_4.out[0x42b618]
./vla_sum_4.out[0x42b92d]
./vla_sum_4.out[0x42bb45]
/lib64/libc.so.6(__libc_start_main+0xf5)[0x7fc2087a6555]
./vla_sum_4.out[0x402d25]
======= Memory map: ========
00400000-0043f000 r-xp 00000000 fd:01 51014653                           /repo/uabelho/master-github/llvm/vla_sum_4.out
0063f000-00640000 r--p 0003f000 fd:01 51014653                           /repo/uabelho/master-github/llvm/vla_sum_4.out
00640000-00643000 rw-p 00040000 fd:01 51014653                           /repo/uabelho/master-github/llvm/vla_sum_4.out
00643000-00f84000 rw-p 00000000 00:00 0 
023ce000-023ef000 rw-p 00000000 00:00 0                                  [heap]
7fc208784000-7fc208948000 r-xp 00000000 fd:00 33598593                   /usr/lib64/libc-2.17.so
7fc208948000-7fc208b47000 ---p 001c4000 fd:00 33598593                   /usr/lib64/libc-2.17.so
7fc208b47000-7fc208b4b000 r--p 001c3000 fd:00 33598593                   /usr/lib64/libc-2.17.so
7fc208b4b000-7fc208b4d000 rw-p 001c7000 fd:00 33598593                   /usr/lib64/libc-2.17.so
7fc208b4d000-7fc208b52000 rw-p 00000000 00:00 0 
7fc208b52000-7fc208b54000 r-xp 00000000 fd:00 34860521                   /usr/lib64/libdl-2.17.so
7fc208b54000-7fc208d54000 ---p 00002000 fd:00 34860521                   /usr/lib64/libdl-2.17.so
7fc208d54000-7fc208d55000 r--p 00002000 fd:00 34860521                   /usr/lib64/libdl-2.17.so
7fc208d55000-7fc208d56000 rw-p 00003000 fd:00 34860521                   /usr/lib64/libdl-2.17.so
7fc208d56000-7fc208e57000 r-xp 00000000 fd:00 34860522                   /usr/lib64/libm-2.17.so
7fc208e57000-7fc209056000 ---p 00101000 fd:00 34860522                   /usr/lib64/libm-2.17.so
7fc209056000-7fc209057000 r--p 00100000 fd:00 34860522                   /usr/lib64/libm-2.17.so
7fc209057000-7fc209058000 rw-p 00101000 fd:00 34860522                   /usr/lib64/libm-2.17.so
7fc209058000-7fc20905f000 r-xp 00000000 fd:00 34860529                   /usr/lib64/librt-2.17.so
7fc20905f000-7fc20925e000 ---p 00007000 fd:00 34860529                   /usr/lib64/librt-2.17.so
7fc20925e000-7fc20925f000 r--p 00006000 fd:00 34860529                   /usr/lib64/librt-2.17.so
7fc20925f000-7fc209260000 rw-p 00007000 fd:00 34860529                   /usr/lib64/librt-2.17.so
7fc209260000-7fc209277000 r-xp 00000000 fd:00 33555219                   /usr/lib64/libpthread-2.17.so
7fc209277000-7fc209476000 ---p 00017000 fd:00 33555219                   /usr/lib64/libpthread-2.17.so
7fc209476000-7fc209477000 r--p 00016000 fd:00 33555219                   /usr/lib64/libpthread-2.17.so
7fc209477000-7fc209478000 rw-p 00017000 fd:00 33555219                   /usr/lib64/libpthread-2.17.so
7fc209478000-7fc20947c000 rw-p 00000000 00:00 0 
7fc20947c000-7fc209491000 r-xp 00000000 fd:00 34815442                   /usr/lib64/libgcc_s-4.8.5-20150702.so.1
7fc209491000-7fc209690000 ---p 00015000 fd:00 34815442                   /usr/lib64/libgcc_s-4.8.5-20150702.so.1
7fc209690000-7fc209691000 r--p 00014000 fd:00 34815442                   /usr/lib64/libgcc_s-4.8.5-20150702.so.1
7fc209691000-7fc209692000 rw-p 00015000 fd:00 34815442                   /usr/lib64/libgcc_s-4.8.5-20150702.so.1
7fc209692000-7fc2096b4000 r-xp 00000000 fd:00 34860516                   /usr/lib64/ld-2.17.so
7fc20987d000-7fc209882000 rw-p 00000000 00:00 0 
7fc2098a2000-7fc2098b3000 rw-p 00000000 00:00 0 
7fc2098b3000-7fc2098b4000 r--p 00021000 fd:00 34860516                   /usr/lib64/ld-2.17.so
7fc2098b4000-7fc2098b5000 rw-p 00022000 fd:00 34860516                   /usr/lib64/ld-2.17.so
7fc2098b5000-7fc2098b6000 rw-p 00000000 00:00 0 
7ffd12f86000-7ffd12fa8000 rw-p 00000000 00:00 0                          [stack]
7ffd12fcc000-7ffd12fce000 r-xp 00000000 00:00 0                          [vdso]
ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0                  [vsyscall]
Abort

vla_sum_4.c1 KBDownload

Mar 3 2022, 12:08 AM · Restricted Project, Restricted Project

Feb 22 2022

uabelho added a comment to D117223: [GlobalOpt] Make global SRA offset based.

In D117223#3337089, @nikic wrote:

@uabelho Thanks for the report, should be fixed by https://github.com/llvm/llvm-project/commit/f8d72100323b127b39fed5f5890b86d81b8a0335.

Feb 22 2022, 2:22 AM · Restricted Project

uabelho added a comment to D119973: RegAllocGreedy: Fix last chance recolor assert in impossible case.

In D119973#3335940, @arsenm wrote:
In D119973#3335832, @arsenm wrote:
In D119973#3335710, @arsenm wrote:
In D119973#3335190, @uabelho wrote:
In a failing example we have a bundle like this with heavy register use:
BUNDLE [...] {
  inst1 %234:Aquad
  inst1 %235:Aquad
  undef %235.sub0:Aquad = inst2 %211:A, %237.sub0:Aquad
  undef %235.sub1:Aquad = inst2 %226:A, %237.sub1:Aquad
  undef %235.sub2:Aquad = inst2 %229:A, %237.sub0:Aquad
  undef %235.sub3:Aquad = inst2 %232:A, %237.sub1:Aquad
}
Can you fill out more context with the surrounding instructions + ranges? Theoretically I can reconstruct the same scenario using -stress-regalloc
So far by guessing I've only seen cases that fail to compile either way. However I'm guessing what we need is the assigned register is a strict superset of the interfering register
Does it work if you change regsOverlap to isSuperRegisterEq?

Feb 22 2022, 12:52 AM · Restricted Project, Restricted Project

Feb 21 2022

uabelho added a comment to D117223: [GlobalOpt] Make global SRA offset based.

and here's the bbi-66447.c

bbi-66447.c166 KBDownload

Feb 21 2022, 7:23 AM · Restricted Project

uabelho added a comment to D117223: [GlobalOpt] Make global SRA offset based.

In D117223#3287388, @nikic wrote:

@uabelho Should be fixed by https://github.com/llvm/llvm-project/commit/236fbf571dc6cebcb81ac5187a170c8de6d5bc0e.

Feb 21 2022, 7:22 AM · Restricted Project

uabelho added a comment to D119973: RegAllocGreedy: Fix last chance recolor assert in impossible case.

In D119973#3334807, @uabelho wrote:

I haven't looked into it yet, but we see cases of "ran out of registers during register allocation" with this patch, for code that compiled succesfully before.

Feb 21 2022, 4:28 AM · Restricted Project, Restricted Project

uabelho added a comment to D119973: RegAllocGreedy: Fix last chance recolor assert in impossible case.

I haven't looked into it yet, but we see cases of "ran out of registers during register allocation" with this patch, for code that compiled succesfully before.

Feb 21 2022, 12:08 AM · Restricted Project, Restricted Project

Feb 17 2022

uabelho added a comment to D113349: [SCEV] Fix and validate ValueExprMap/ExprValueMap consistency.

I wrote
https://github.com/llvm/llvm-project/issues/53905
that started happening with this patch.

Feb 17 2022, 9:03 AM · Restricted Project

Feb 16 2022

uabelho added a comment to D119855: [SLP]Fix vectorization of the alternate cmp instruction with swapped predicates..

I can confirm that this patch fixes the miscompile I saw in
https://reviews.llvm.org/D115955#3322857

Feb 16 2022, 11:44 PM · Restricted Project

uabelho added a comment to D117174: [libc++][test] Run clang-tidy during CI.

In D117174#3325739, @bjope wrote:

In D117174#3325369, @uabelho wrote:

Any idea?

I guess the new test ends up using clang-tidy from the PATH(?) rather than from the just built compiler. And that version might be too old if for example using llvm8.0 when building the compiler.
So should perhaps the has-clang-tidy check be more picky about which version of clang-tidy that is found?

Feb 16 2022, 3:52 AM · Restricted Project

Feb 15 2022

uabelho added a comment to D117174: [libc++][test] Run clang-tidy during CI.

No idea what's happening but I get this error on trunk

FAIL: libc++ :: libcxx/clang_tidy.sh.cpp (600 of 7776)
******************** TEST 'libc++ :: libcxx/clang_tidy.sh.cpp' FAILED ********************
Script:
--
: 'RUN: at line 11';   clang-tidy /repo/uabelho/master-github/libcxx/test/libcxx/clang_tidy.sh.cpp --warnings-as-errors=* -header-filter=.* -- -Wno-unknown-warning-option -nostdinc++ -isystem /repo/uabelho/master-github/llvm/build-all-builtins/include/x86_64-unknown-linux-gnu/c++/v1 -isystem /repo/uabelho/master-github/llvm/build-all-builtins/include/c++/v1 -I/repo/uabelho/master-github/llvm/build-all-builtins/runtimes/runtimes-x86_64-unknown-linux-gnu-bins/libcxx/include/c++build -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -I/repo/uabelho/master-github/libcxx/test/support -std=c++2b -Werror -Wall -Wextra -Wshadow -Wundef -Wno-unused-command-line-argument -Wno-attributes -Wno-pessimizing-move -Wno-c++11-extensions -Wno-user-defined-literals -Wno-noexcept-type -Wno-atomic-alignment -Wsign-compare -Wunused-variable -Wunused-parameter -Wunreachable-code -Wno-unused-local-typedef -D_LIBCPP_DISABLE_AVAILABILITY -fcoroutines-ts -Werror=thread-safety -Wuser-defined-warnings -D_LIBCPP_HAS_NO_PRAGMA_SYSTEM_HEADER
--
Exit Code: 1

Feb 15 2022, 11:18 PM · Restricted Project

uabelho added inline comments to rG4a794d848ce8: [Bitstream] Improve error propagation from ReadVBR.

Feb 15 2022, 10:19 PM

uabelho added a comment to D115955: [SLP]Alternate vectorization for cmp instructions..

In D115955#3322721, @ABataev wrote:

In D115955#3322699, @uabelho wrote:

In D115955#3322693, @ABataev wrote:

In D115955#3322678, @uabelho wrote:

I think I'm seeing a miscompile with this patch on trunk. Are we aware of any such problems?

Do you have a reproducer or something like this?

Not yet. I'm trying to extract something but thought I'd ask if you're already aware of any miscompilation problems in the meantime.

No.

Feb 15 2022, 6:52 AM · Restricted Project

uabelho added a comment to D115955: [SLP]Alternate vectorization for cmp instructions..

In D115955#3322693, @ABataev wrote:

In D115955#3322678, @uabelho wrote:

I think I'm seeing a miscompile with this patch on trunk. Are we aware of any such problems?

Do you have a reproducer or something like this?

Feb 15 2022, 5:37 AM · Restricted Project

uabelho added a comment to D115955: [SLP]Alternate vectorization for cmp instructions..

I think I'm seeing a miscompile with this patch on trunk. Are we aware of any such problems?

Feb 15 2022, 5:27 AM · Restricted Project

Feb 13 2022

uabelho added a comment to D119270: [analyzer] Re-enables trustnonnullchecker_test and removes redundant code from TrustNonNullChecker.

WIth EXPENSIVE_CHECKS this testcase now fails all the time.
So

build-all-expensive/bin/clang -cc1 -internal-isystem build-all-expensive/lib/clang/15.0.0/include -nostdsysteminc -analyze -analyzer-constraints=range -setup-static-analyzer -fblocks -analyze -analyzer-checker=core,nullability,apiModeling,debug.ExprInspection  -verify ../clang/test/Analysis/trustnonnullchecker_test.m

fails with

clang: ../../clang/include/clang/StaticAnalyzer/Core/PathSensitive/ConstraintManager.h:100: clang::ento::ConstraintManager::ProgramStatePair clang::ento::ConstraintManager::assumeDual(clang::ento::ProgramStateRef, clang::ento::DefinedSVal): Assertion `assume(State, Cond, false) && "System is over constrained."' failed.
PLEASE submit a bug report to https://github.com/llvm/llvm-project/issues/ and include the crash backtrace, preprocessed source, and associated run script.
Stack dump:
0.	Program arguments: build-all-expensive/bin/clang -cc1 -internal-isystem build-all-expensive/lib/clang/15.0.0/include -nostdsysteminc -analyze -analyzer-constraints=range -setup-static-analyzer -fblocks -analyze -analyzer-checker=core,nullability,apiModeling,debug.ExprInspection -verify ../clang/test/Analysis/trustnonnullchecker_test.m
1.	<eof> parser at end of file
2.	While analyzing stack: 
	#0 Calling -[DictionarySubclass coder]
3.	../clang/test/Analysis/trustnonnullchecker_test.m:190:9: Error evaluating branch
Stack dump without symbol names (ensure you have llvm-symbolizer in your PATH or set the environment var `LLVM_SYMBOLIZER_PATH` to point to it):
build-all-expensive/bin/clang(_ZN4llvm3sys15PrintStackTraceERNS_11raw_ostreamEi+0x23)[0x2e66ae3]
build-all-expensive/bin/clang(_ZN4llvm3sys17RunSignalHandlersEv+0xee)[0x2e6475e]
build-all-expensive/bin/clang[0x2e66e66]
/lib64/libpthread.so.0(+0xf630)[0x7f5af3a04630]
/lib64/libc.so.6(gsignal+0x37)[0x7f5af1137387]
/lib64/libc.so.6(abort+0x148)[0x7f5af1138a78]
/lib64/libc.so.6(+0x2f1a6)[0x7f5af11301a6]
/lib64/libc.so.6(+0x2f252)[0x7f5af1130252]
build-all-expensive/bin/clang[0x4143927]
build-all-expensive/bin/clang(_ZN5clang4ento10ExprEngine13processBranchEPKNS_4StmtERNS0_18NodeBuilderContextEPNS0_12ExplodedNodeERNS0_15ExplodedNodeSetEPKNS_8CFGBlockESD_+0xaae)[0x44fd8de]
build-all-expensive/bin/clang(_ZN5clang4ento10CoreEngine12HandleBranchEPKNS_4StmtES4_PKNS_8CFGBlockEPNS0_12ExplodedNodeE+0xa1)[0x44dafd1]
build-all-expensive/bin/clang(_ZN5clang4ento10CoreEngine15ExecuteWorkListEPKNS_15LocationContextEjN4llvm18IntrusiveRefCntPtrIKNS0_12ProgramStateEEE+0x4a4)[0x44d9624]
build-all-expensive/bin/clang[0x4118d2c]
build-all-expensive/bin/clang[0x40fc6aa]
build-all-expensive/bin/clang(_ZN5clang8ParseASTERNS_4SemaEbb+0x273)[0x45f2633]
build-all-expensive/bin/clang(_ZN5clang14FrontendAction7ExecuteEv+0x106)[0x38464a6]
build-all-expensive/bin/clang(_ZN5clang16CompilerInstance13ExecuteActionERNS_14FrontendActionE+0x144)[0x37c19e4]
build-all-expensive/bin/clang(_ZN5clang25ExecuteCompilerInvocationEPNS_16CompilerInstanceE+0x2a2)[0x3901152]
build-all-expensive/bin/clang(_Z8cc1_mainN4llvm8ArrayRefIPKcEES2_Pv+0x5fa)[0xa2980a]
build-all-expensive/bin/clang[0xa27c2f]
build-all-expensive/bin/clang(main+0x2c73)[0xa277c3]
/lib64/libc.so.6(__libc_start_main+0xf5)[0x7f5af1123555]
build-all-expensive/bin/clang[0xa24849]
Abort

Feb 13 2022, 11:58 PM · Restricted Project

Feb 9 2022

uabelho added inline comments to D98110: [NFC][clangd] Use table to collect option aliases.

Feb 9 2022, 1:58 AM · Restricted Project, Restricted Project

Feb 8 2022

uabelho added inline comments to D117147: [MLGO] ML Regalloc Eviction Advisor.

Feb 8 2022, 1:03 AM · Restricted Project

uabelho added inline comments to D117147: [MLGO] ML Regalloc Eviction Advisor.

Feb 8 2022, 12:58 AM · Restricted Project

uabelho added inline comments to D117147: [MLGO] ML Regalloc Eviction Advisor.

Feb 8 2022, 12:10 AM · Restricted Project

Feb 2 2022

uabelho added a comment to D109450: [IRSim][IROutliner] Allowing Intrinsic Calls to be Used in Similarity Matching and Outlined Regions.

In D109450#3283855, @uabelho wrote:
Hello,

The following fails with this commit:
opt -passes='require<ir-similarity>' -o /dev/null bbi-65410.ll

Feb 2 2022, 2:32 AM · Restricted Project

Feb 1 2022

uabelho added a comment to D117223: [GlobalOpt] Make global SRA offset based.

In D117223#3287388, @nikic wrote:

@uabelho Should be fixed by https://github.com/llvm/llvm-project/commit/236fbf571dc6cebcb81ac5187a170c8de6d5bc0e.

Feb 1 2022, 7:37 AM · Restricted Project

uabelho added a comment to D117223: [GlobalOpt] Make global SRA offset based.

We've seen a case where the output from opt is different with/without debug info and ended up bisection at this patch.
After reduction and fiddling it seems like it doesn't actually have to do with debug info at all but something else. Our best reproducer so far is as below.

Feb 1 2022, 4:14 AM · Restricted Project

Jan 31 2022

uabelho added a comment to D109450: [IRSim][IROutliner] Allowing Intrinsic Calls to be Used in Similarity Matching and Outlined Regions.

The following fails with this commit:

opt -passes='require<ir-similarity>' -o /dev/null bbi-65410.ll

Result:

opt: ../lib/Analysis/IRSimilarityIdentifier.cpp:998: void llvm::IRSimilarity::IRSimilarityCandidate::createCanonicalRelationFrom(llvm::IRSimilarity::IRSimilarityCandidate &, DenseMap<unsigned int, DenseSet<unsigned int> > &, DenseMap<unsigned int, DenseSet<unsigned int> > &): Assertion `Found && "Could not find matching value for source GVN"' failed.
PLEASE submit a bug report to https://github.com/llvm/llvm-project/issues/ and include the crash backtrace.
Stack dump:
0.	Program arguments: build-all/bin/opt -passes=require<ir-similarity> -o /dev/null bbi-65410.ll
 #0 0x0000000002cbb993 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) (build-all/bin/opt+0x2cbb993)
 #1 0x0000000002cb960e llvm::sys::RunSignalHandlers() (build-all/bin/opt+0x2cb960e)
 #2 0x0000000002cbbd16 SignalHandler(int) Signals.cpp:0:0
 #3 0x00007fcc4be0e630 __restore_rt sigaction.c:0:0
 #4 0x00007fcc49541387 raise (/lib64/libc.so.6+0x36387)
 #5 0x00007fcc49542a78 abort (/lib64/libc.so.6+0x37a78)
 #6 0x00007fcc4953a1a6 __assert_fail_base (/lib64/libc.so.6+0x2f1a6)
 #7 0x00007fcc4953a252 (/lib64/libc.so.6+0x2f252)
 #8 0x0000000001b4f5aa llvm::IRSimilarity::IRSimilarityCandidate::createCanonicalRelationFrom(llvm::IRSimilarity::IRSimilarityCandidate&, llvm::DenseMap<unsigned int, llvm::DenseSet<unsigned int, llvm::DenseMapInfo<unsigned int, void> >, llvm::DenseMapInfo<unsigned int, void>, llvm::detail::DenseMapPair<unsigned int, llvm::DenseSet<unsigned int, llvm::DenseMapInfo<unsigned int, void> > > >&, llvm::DenseMap<unsigned int, llvm::DenseSet<unsigned int, llvm::DenseMapInfo<unsigned int, void> >, llvm::DenseMapInfo<unsigned int, void>, llvm::detail::DenseMapPair<unsigned int, llvm::DenseSet<unsigned int, llvm::DenseMapInfo<unsigned int, void> > > >&) (build-all/bin/opt+0x1b4f5aa)
 #9 0x0000000001b504d1 llvm::IRSimilarity::IRSimilarityIdentifier::findCandidates(std::vector<llvm::IRSimilarity::IRInstructionData*, std::allocator<llvm::IRSimilarity::IRInstructionData*> >&, std::vector<unsigned int, std::allocator<unsigned int> >&) (build-all/bin/opt+0x1b504d1)
#10 0x0000000001b512ba llvm::IRSimilarity::IRSimilarityIdentifier::findSimilarity(llvm::Module&) (build-all/bin/opt+0x1b512ba)
#11 0x0000000001b5185a llvm::IRSimilarityAnalysis::run(llvm::Module&, llvm::AnalysisManager<llvm::Module>&) (build-all/bin/opt+0x1b5185a)
#12 0x0000000002fc43a0 llvm::detail::AnalysisPassModel<llvm::Module, llvm::IRSimilarityAnalysis, llvm::PreservedAnalyses, llvm::AnalysisManager<llvm::Module>::Invalidator>::run(llvm::Module&, llvm::AnalysisManager<llvm::Module>&) crtstuff.c:0:0
#13 0x000000000241321e llvm::AnalysisManager<llvm::Module>::getResultImpl(llvm::AnalysisKey*, llvm::Module&) (build-all/bin/opt+0x241321e)
#14 0x0000000002fd0e88 llvm::RequireAnalysisPass<llvm::IRSimilarityAnalysis, llvm::Module, llvm::AnalysisManager<llvm::Module> >::run(llvm::Module&, llvm::AnalysisManager<llvm::Module>&) crtstuff.c:0:0
#15 0x0000000002fd0ccd llvm::detail::PassModel<llvm::Module, llvm::RequireAnalysisPass<llvm::IRSimilarityAnalysis, llvm::Module, llvm::AnalysisManager<llvm::Module> >, llvm::PreservedAnalyses, llvm::AnalysisManager<llvm::Module> >::run(llvm::Module&, llvm::AnalysisManager<llvm::Module>&) crtstuff.c:0:0
#16 0x0000000002410a98 llvm::PassManager<llvm::Module, llvm::AnalysisManager<llvm::Module> >::run(llvm::Module&, llvm::AnalysisManager<llvm::Module>&) (build-all/bin/opt+0x2410a98)
#17 0x000000000079e0a2 llvm::runPassPipeline(llvm::StringRef, llvm::Module&, llvm::TargetMachine*, llvm::TargetLibraryInfoImpl*, llvm::ToolOutputFile*, llvm::ToolOutputFile*, llvm::ToolOutputFile*, llvm::StringRef, llvm::ArrayRef<llvm::StringRef>, llvm::opt_tool::OutputKind, llvm::opt_tool::VerifierKind, bool, bool, bool, bool, bool) (build-all/bin/opt+0x79e0a2)
#18 0x00000000007b0c74 main (build-all/bin/opt+0x7b0c74)
#19 0x00007fcc4952d555 __libc_start_main (/lib64/libc.so.6+0x22555)
#20 0x000000000079952c _start (build-all/bin/opt+0x79952c)
Abort

bbi-65410.ll643 BDownload

Jan 31 2022, 6:42 AM · Restricted Project

Jan 25 2022

uabelho added a comment to D116895: Fix a missed opportunity to optimize consecutive stores..

Anyone seen problems with this patch?
I have a case for my out-of-tree target where this patch causes two stores to be merged leading to a cycle in the DAG.
So in the initial DAG we have the following dependencies

store2 <- load1 <- load2 <- load3 <- store1

and then store2 and store1 are merged to store21 and we end up with dependencies like this:

store12 <- load1 <- load2 <- load3
                          <- store12

ie. load2 depends on both load3 and store12 so we have a broken DAG with a cycle in it.
So then we end up with

Operand not processed?0x882a240
t9: i16,ch = load<(load (s16) from %ir.next1.i)> t26, t8, undef:i16

Jan 25 2022, 7:38 AM · Restricted Project

uabelho (Mikael Holmén)User

Projects

User Details

Recent ActivityView All

Mon, Jun 13

Thu, Jun 9

Jun 7 2022

Jun 3 2022

Jun 2 2022

Jun 1 2022

May 31 2022

May 30 2022

May 20 2022

May 18 2022

May 17 2022

May 13 2022

May 12 2022

May 11 2022

May 10 2022

May 9 2022

May 8 2022

May 6 2022

Apr 26 2022

Apr 22 2022

Apr 18 2022

Apr 17 2022

Apr 14 2022

Apr 7 2022

Apr 5 2022

Apr 4 2022

Mar 31 2022

Mar 30 2022

Mar 29 2022

Mar 28 2022

Mar 24 2022

Mar 21 2022

Mar 18 2022

Mar 17 2022

Mar 13 2022

Mar 11 2022

Mar 8 2022

Mar 6 2022

Mar 4 2022

Mar 3 2022

Feb 22 2022

Feb 21 2022

Feb 17 2022

Feb 16 2022

Feb 15 2022

Feb 13 2022

Feb 9 2022

Feb 8 2022

Feb 2 2022

Feb 1 2022

Jan 31 2022

Jan 25 2022

uabelho (Mikael Holmén)
User

Recent Activity
View All