[llvm-dev] Assertion in MachineScheduler.cpp
Rail Shafigulin via llvm-dev
llvm-dev at lists.llvm.org
Thu Apr 28 11:17:45 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:
>
For my architecture R0 is a physical register. It always has a value of 0.
>
> 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.
Am I correct assuming that kill means get rid of the register?
> 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.
>
Does it mean that I have to make changes to the core code (register
pressure tracker) or I can get away with changes to my target? Obviously
the latter is preferred.
> 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.
>
Am I correct assuming that by the "case" you mean kill of the physical
register? I'm not familiar with ToT abbreviation? What does it mean?
>
> -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/5906bab8/attachment.html>
More information about the llvm-dev
mailing list