[llvm-dev] Assertion in MachineScheduler.cpp

Rail Shafigulin via llvm-dev llvm-dev at lists.llvm.org
Thu Apr 28 12:11:27 PDT 2016


On Thu, Apr 28, 2016 at 6:13 AM, Krzysztof Parzyszek <
kparzysz at codeaurora.org> wrote:

> 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,

What is 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
>



-- 
Rail Shafigulin
Software Engineer
Esencia Technologies
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160428/a91d2e78/attachment.html>


More information about the llvm-dev mailing list