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