[llvm-dev] FireFox-46.0.1 build with interprocedural register allocation enabled

[vivek pandya via llvm-dev]

On Tue, Jun 21, 2016 at 8:58 AM, Mehdi Amini <mehdi.amini at apple.com> wrote:

>
> On Jun 20, 2016, at 3:00 PM, vivek pandya via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
>
>
>
> On Mon, Jun 20, 2016 at 10:05 PM, Sanjoy Das <
> sanjoy at playingwithpointers.com> wrote:
>
>> Hi Vivek,
>>
>> vivek pandya wrote:
>>
>> > For Octane and Kraken I have run them 4 times and above result is
>> > geometric mean. For Octane standard deviation (SD) is
>> > 918.54 (NO_IPRA) and 597.82 (With_IPRA). For Kraken unfortunately I
>> > don't have readings any more but there was very
>> > minor change in each run. JetStream it self runs the test for 3
>> > times reports the result. From next time onwards I will
>> > run test at least for 10 times
>>
>> Oh, no, I used "10 times" as an anecdotal number.  Geomean of 4 times
>> is enough.  Of course, if it does not take extra effort, running them
>> for more iterations is better, but don't bother if it will e.g. take
>> more than a trivial amount of manual work.
>>
>> >     It'd also be great to have a precise, non-measurement oriented view
>> of
>> >     the benchmarks.
>> >
>> > I don't understand this point actually all these benchmarks are
>> > suggested by firefox-devs and they wanted the results back.
>>
>> I was talking about the `-stats` bit there ^.
>>
>> >     Is it possible to collect some statistics on how much
>> >     you've improved the register allocation in these workloads?
>> >
>> > Actually while testing single source test case with debug build I
>> > used to compare results of -stats with regalloc
>> > keyword but while building such a huge software I prefer release
>> > build of llvm. And also I don't know if there is any
>> > way in llvm to generate stats for the whole build.
>>
>> Can you do something quick and dirty, like just have some local
>> changes that dumps out some information on outs() ?
>
> Yes that should not take too much of time.
>
>>
>>
>> >     Perhaps
>> >     you could count the instances where you preserved a register over a
>> >     call site that wouldn't have been possible without IPRA?
>> >
>> > Yes this seems a good idea and I think this is implementable, after
>> > calculating new regmask when inserting data into
>> > immutable pass two regmasks can be compared to calculate
>> > improvements. I will work on this and let you know the progress.
>>
>> Just to be clear: you don't *have* to do this (specifically, check
>> with your mentor before sinking too much time into this).  But if we
>> can come up with easy to "confirm your kill" (i.e. ensure what you
>> think should happen is what is actually happening) then I think we
>> should do it.
>>
> I will try if this can be done in a simple way. I am sure mentors will
> welcome it.
>
>
> Yes having more stats seems a nice thing to have.
>
> Hello ,
I did some quick and dirty hack for calculating no of register preserved
due to IPRA:

std::vector<uint32_t> RegMaskCopy = RegMask;
const uint32_t *CallPreservedMaskCopy =
      TRI->getCallPreservedMask(MF, MF.getFunction()->getCallingConv());
// calculate improvement by counting no of bits set.
unsigned int count = 0;
for (unsigned PReg = 1, PRegE = TRI->getNumRegs(); PReg < PRegE; ++PReg) {
  if(!(CallPreservedMaskCopy[PReg / 32] & (1u << PReg % 32))
      && (RegMaskCopy[PReg / 32] & (1u << PReg % 32))){
    markRegClobbered(TRI, &RegMaskCopy[0], PReg); // set aliases to 0
    count++;
  }
}
outs() << "Improvement Due to IPRA : " << count << "\n";

Is this seem good?
-Vivek

> —
> Mehdi
>
>
> -Vivek
>
>>
>> Thanks, and best of luck!
>> -- Sanjoy
>>
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160621/52bd1c2c/attachment-0001.html>