[llvm-dev] Assertion in MachineScheduler.cpp
Krzysztof Parzyszek via llvm-dev
llvm-dev at lists.llvm.org
Thu Apr 28 06:13:27 PDT 2016
There are uses of R0 all over the place, even though R0 is not marked as
live-in to any of the blocks that use it. For example:
BB#45: derived from LLVM BB %sw.bb54
Predecessors according to CFG: BB#43 BB#44
DBG_VALUE %vreg287, %noreg, !"base"
%vreg203<def> = LWZ <fi#5>, 0; mem:LD4[%args] GPR:%vreg203
%vreg204<def> = ADDI %vreg203, 3; GPR:%vreg204,%vreg203
--> %vreg205<def> = ADDI %R0, -4; GPR:%vreg205
%vreg206<def> = AND %vreg204, %vreg205;
GPR:%vreg206,%vreg204,%vreg205
%vreg207<def> = ADDI %vreg206, 4; GPR:%vreg207,%vreg206
%vreg290<def> = LWZ %vreg206, 0; mem:LD4[<unknown>]
GPR:%vreg290,%vreg206
SFGTS_ri %vreg290, -1, %SR<imp-def>; GPR:%vreg290
BF <BB#48>, %SR<imp-use,kill>
J <BB#46>
Successors according to CFG: BB#46(186) BB#48(62)
IIRC, at some point the register pressure tracker assumed that a use of
a physical register is always a kill, thus it would always decrease
register pressure on the class that the register belonged to. If that
assumption is false, the decrease would be incorrect and could lead to
an underflow.
The "proper" usage of a physical register would be to mark it as a
live-in to the block, and then have a COPY instruction that would
transfer it into a virtual register, which would then be used in the ADDI.
Since you are using llvm 3.5, that may still be the case for you. I'm
not sure whether this is still necessary in ToT.
-Krzysztof
On 4/27/2016 6:08 PM, Rail Shafigulin wrote:
> I'm attaching an output of -mllvm -debug command. The output is large
> but i'm hoping it contains everything that is needed. If anyone needs
> more, just ask.
>
> Any help in resolving the issue is appreciated.
>
> On Wed, Apr 27, 2016 at 2:52 PM, Rail Shafigulin <rail at esenciatech.com
> <mailto:rail at esenciatech.com>> wrote:
>
>
> Apologies if my questions sound dumb. They are provided below.
>
> On Wed, Apr 27, 2016 at 2:43 PM, Krzysztof Parzyszek
> <kparzysz at codeaurora.org <mailto:kparzysz at codeaurora.org>> wrote:
>
> Are there any instructions (other than COPY) that use hardware
> (allocatable) registers?
>
> How do I find that out?
>
>
> Could you show the instructions in the scheduling range?
>
> How can I see instructions in the current scheduling range?
>
>
> -Krzysztof
>
>
> On 4/27/2016 3:44 PM, Rail Shafigulin wrote:
>
> Thanks for the suggestion.
>
> I tried your fix. It worked for my particular case, but then
> I got a
> following error:
>
> clang-3.5:
> /home/rail/projects/escala_llvm/trunk/llvm-or1k/lib/CodeGen/RegisterPressure.cpp:39:
> void decreaseSetPressure(std::vector<unsigned int>&,
> llvm::PSetIterator): Assertion `CurrSetPressure[*PSetI] >=
> Weight &&
> "register pressure underflow"' failed.
>
> Do you mind helping me out? A stack dump is provided below:
>
> clang-3.5:
> /home/rail/projects/escala_llvm/trunk/llvm-or1k/lib/CodeGen/RegisterPressure.cpp:39:
> void decreaseSetPressure(std::vector<unsigned int>&,
> llvm::PSetIterator): Assertion `CurrSetPressure[*PSetI] >=
> Weight &&
> "register pressure underflow"' failed.
> 0 clang-3.5 0x00000000017dfae4
> llvm::sys::PrintStackTrace(_IO_FILE*) + 38
> 1 clang-3.5 0x00000000017dfd61
> 2 clang-3.5 0x00000000017df715
> 3 libpthread.so.0 0x00002ad3b4a17340
> 4 libc.so.6 0x00002ad3b547bcc9 gsignal + 57
> 5 libc.so.6 0x00002ad3b547f0d8 abort + 328
> 6 libc.so.6 0x00002ad3b5474b86
> 7 libc.so.6 0x00002ad3b5474c32
> 8 clang-3.5 0x0000000001de82a3
> 9 clang-3.5 0x0000000001de880c
> llvm::RegPressureTracker::decreaseRegPressure(llvm::ArrayRef<unsigned
> int>) + 120
> 10 clang-3.5 0x0000000001dec305
> llvm::RegPressureTracker::bumpDownwardPressure(llvm::MachineInstr
> const*) + 593
> 11 clang-3.5 0x0000000001dec4da
> llvm::RegPressureTracker::getMaxDownwardPressureDelta(llvm::MachineInstr
> const*, llvm::RegPressureDelta&,
> llvm::ArrayRef<llvm::PressureChange>,
> llvm::ArrayRef<unsigned int>) + 138
> 12 clang-3.5 0x0000000000e4c60f
> 13 clang-3.5 0x0000000000e4f066
> llvm::ConvergingVLIWScheduler::pickNodeFromQueue(llvm::ReadyQueue&,
> llvm::RegPressureTracker const&,
> llvm::ConvergingVLIWScheduler::SchedCandidate&) + 284
> 14 clang-3.5 0x0000000000e4f2e5
> llvm::ConvergingVLIWScheduler::pickNodeBidrectional(bool&) + 285
> 15 clang-3.5 0x0000000000e4f5b0
> llvm::ConvergingVLIWScheduler::pickNode(bool&) + 576
> 16 clang-3.5 0x0000000000e4db8e
> llvm::VLIWMachineScheduler::schedule() + 1366
> 17 clang-3.5 0x0000000001d7830f
> 18 clang-3.5 0x0000000001d77988
> 19 clang-3.5 0x0000000001d4f9c7
> llvm::MachineFunctionPass::runOnFunction(llvm::Function&) + 95
> 20 clang-3.5 0x00000000014dacee
> llvm::FPPassManager::runOnFunction(llvm::Function&) + 290
> 21 clang-3.5 0x00000000014dae5e
> llvm::FPPassManager::runOnModule(llvm::Module&) + 84
> 22 clang-3.5 0x00000000014db17c
> 23 clang-3.5 0x00000000014db766
> llvm::legacy::PassManagerImpl::run(llvm::Module&) + 244
> 24 clang-3.5 0x00000000014db971
> llvm::legacy::PassManager::run(llvm::Module&) + 39
> 25 clang-3.5 0x0000000001ef9c4b
> 26 clang-3.5 0x0000000001ef9d1a
> clang::EmitBackendOutput(clang::DiagnosticsEngine&,
> clang::CodeGenOptions const&, clang::TargetOptions const&,
> clang::LangOptions const&, llvm::StringRef, llvm::Module*,
> clang::BackendAction, llvm::raw_ostream*) + 127
> 27 clang-3.5 0x0000000001ef3637
> 28 clang-3.5 0x000000000276b1ea
> clang::ParseAST(clang::Sema&,
> bool, bool) + 780
> 29 clang-3.5 0x00000000019992b0
> clang::ASTFrontendAction::ExecuteAction() + 322
> 30 clang-3.5 0x0000000001ef4fb8
> clang::CodeGenAction::ExecuteAction() + 1362
> 31 clang-3.5 0x0000000001998de3
> clang::FrontendAction::Execute() + 205
> 32 clang-3.5 0x000000000196c770
> clang::CompilerInstance::ExecuteAction(clang::FrontendAction&)
> + 720
> 33 clang-3.5 0x0000000001a8b277
> clang::ExecuteCompilerInvocation(clang::CompilerInstance*) +
> 1029
> 34 clang-3.5 0x0000000000e36a09 cc1_main(char const**,
> char
> const**, char const*, void*) + 717
> 35 clang-3.5 0x0000000000e312f4 main + 785
> 36 libc.so.6 0x00002ad3b5466ec5 __libc_start_main + 245
> 37 clang-3.5 0x0000000000e2e959
>
>
>
>
>
> On Wed, Apr 27, 2016 at 11:41 AM, Krzysztof Parzyszek via
> llvm-dev
> <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>
> <mailto:llvm-dev at lists.llvm.org
> <mailto:llvm-dev at lists.llvm.org>>> wrote:
>
> On 4/27/2016 12:10 PM, Rail Shafigulin via llvm-dev wrote:
>
>
> The first error that I see during compilation is
>
> lib/CodeGen/MachineScheduler.cpp:1165: void
> llvm::ScheduleDAGMILive::scheduleMI(llvm::SUnit*,
> bool): Assertion
> `TopRPTracker.getPos() == CurrentTop && "out of
> sync"' failed.
>
>
> This happens on Hexagon too. I have a patch for review:
> http://reviews.llvm.org/D19438
>
> -Krzysztof
>
>
> --
> Qualcomm Innovation Center, Inc. is a member of Code
> Aurora Forum,
> hosted by The Linux Foundation
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>
> <mailto:llvm-dev at lists.llvm.org
> <mailto:llvm-dev at lists.llvm.org>>
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
>
>
>
> --
> Rail Shafigulin
> Software Engineer
> Esencia Technologies
>
>
>
> --
> Qualcomm Innovation Center, Inc. is a member of Code Aurora
> Forum, hosted by The Linux Foundation
>
>
>
>
> --
> Rail Shafigulin
> Software Engineer
> Esencia Technologies
>
>
>
>
> --
> Rail Shafigulin
> Software Engineer
> Esencia Technologies
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation
More information about the llvm-dev
mailing list