Krzysztof Parzyszek via llvm-dev
2016-Apr-28 13:13 UTC
[llvm-dev] Assertion in MachineScheduler.cpp
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
Rail Shafigulin via llvm-dev
2016-Apr-28 18:17 UTC
[llvm-dev] Assertion in MachineScheduler.cpp
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>
Krzysztof Parzyszek via llvm-dev
2016-Apr-28 18:54 UTC
[llvm-dev] Assertion in MachineScheduler.cpp
On 4/28/2016 1:17 PM, Rail Shafigulin wrote:> > On Thu, Apr 28, 2016 at 6:13 AM, Krzysztof Parzyszek > <kparzysz at codeaurora.org <mailto: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.Ah, ok. I'm guessing it's already marked as "reserved", right?> 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?Kill is the last use of the register after its most recent definition. After this point the register is "dead", i.e. no longer used.> 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.If R0 is reserved, you should be fine without any changes. In such case, I don't really know what the problem is. I still suspect that the R0 is not handled right somewhere, but I have no idea where exactly.> 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?ToT = tip of the tree, the latest source tree of LLVM/clang. -Krzysztof -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation
Rail Shafigulin via llvm-dev
2016-Apr-28 19:11 UTC
[llvm-dev] Assertion in MachineScheduler.cpp
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>
Krzysztof Parzyszek via llvm-dev
2016-Apr-28 19:21 UTC
[llvm-dev] Assertion in MachineScheduler.cpp
On 4/28/2016 2:11 PM, Rail Shafigulin wrote:> > On Thu, Apr 28, 2016 at 6:13 AM, Krzysztof Parzyszek > <kparzysz at codeaurora.org <mailto:kparzysz at codeaurora.org>> wrote: > > > IIRC, > > What is IIRC?If I remember correctly... -Krzysztof -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation