llvm dev - Aug 2013 - [LLVMdev] [polly] one more slow pretty printing in the default path

Hi,

in lib/Analysis/RegionPass.cpp there are 3 occurrences of:
CurrentRegion->getNameStr()
These are slowing down compile times with polly.
I would suggest to either remove these calls,
or only turn on when the programmer asks for -debug.

The reason for the slow pretty printing of types is the same as
previously discussed in:
http://lists.cs.uiuc.edu/pipermail/llvmdev/2013-July/063755.html

Sebastian
-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation

On 08/28/2013 10:08 AM, Sebastian Pop wrote:
> Hi,tic
>
> in lib/Analysis/RegionPass.cpp there are 3 occurrences of:
> CurrentRegion->getNameStr()
> These are slowing down compile times with polly.
> I would suggest to either remove these calls,
> or only turn on when the programmer asks for -debug.
>
> The reason for the slow pretty printing of types is the same as
> previously discussed in:
> http://lists.cs.uiuc.edu/pipermail/llvmdev/2013-July/063755.html
Just removing those calls looks like a hack as it yields -analyse output
without named regions.

On the other side, having calls to WriteAsOperand in 
Region::getNameStr() is the cause of this slowdown. It helps us to 
provide a reasonable way to name regions that do have unnamed basic 
blocks. If we can find a better/faster way to name such regions we could
remove the call to WriteAsOperand without regrets. We could e.g. just
assign an increasing number to each new region and just call them 
region_<number>.

Cheers,
Tobi

At 2013-08-29 03:44:05,"Tobias Grosser" <tobias at
grosser.es> wrote:>On 08/28/2013 10:08 AM, Sebastian Pop wrote:
>> Hi,tic
>>
>> in lib/Analysis/RegionPass.cpp there are 3 occurrences of:
>> CurrentRegion->getNameStr()
>> These are slowing down compile times with polly.
>> I would suggest to either remove these calls,
>> or only turn on when the programmer asks for -debug.
>>
>> The reason for the slow pretty printing of types is the same as
>> previously discussed in:
>> http://lists.cs.uiuc.edu/pipermail/llvmdev/2013-July/063755.html
>
>Just removing those calls looks like a hack as it yields -analyse output
>without named regions.
>
>On the other side, having calls to WriteAsOperand in 
>Region::getNameStr() is the cause of this slowdown. It helps us to 
>provide a reasonable way to name regions that do have unnamed basic 
>blocks. If we can find a better/faster way to name such regions we could
>remove the call to WriteAsOperand without regrets. We could e.g. just
>assign an increasing number to each new region and just call them 
>region_<number>.
>
I think it may be not easy to understand the mapping relationship between
regions and basic blocks if we simplify call them region_<number>.  Since
the key problem is to identify anonymous basic blocks, maybe we can try to
obtain the sequence number of those anonymous basic blocks. In that case, we can
simplify the Region:getNameStr() into:

if (getEntry()->getName().empty()) {
    //    raw_string_ostream OS(entryName);
    //    WriteAsOperand(OS, getEntry(), false);
    entryName = "BB#" + getEntry()->getGlobalSequenceNumber();
 //getGlobalSequenceNumber is required to be implemented!
  } else
    entryName = getEntry()->getName();

which is similar to the way used in MachineBasicBlock class. Of course, we need
to implement the getGlbalSequenceNumber() or similar functions.

BTW, has anyone already had a testcase that will produce regions with anonymous
basic block.  I can have a  try to fix this problem.

Star
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20130902/450ac633/attachment.html>