llvm dev - Apr 2019 - Today is the last day of mediocre library call optimizations

To this day, we still do too little when it comes to optimizing well
known library calls.

Given that various libraries, especially the C/C++ standard library, are
relatively clear defined, and LLVM has all the infrastructure already in
place, e.g., SimplifyLibCalls.cpp, it seems odd that we still miss so
many optimization opportunities.

To show how easy it is, and how much impact it can have, I crafted a
very simple, yet very effective patch which will hopefully only be the
first of its kind.

The attached twelve line addition to SimplifyLibCalls.cpp provides
subsequent passes with a better understanding of the "getenv"
function.

This function was chosen to showcase the enormous impact well placed
information can have on real world software, including LLVM itself.

While you could take my word for it, I would encourage you to try it out
yourself. Apply the patch and create *a new build* of LLVM to compare
against your existing one. I firmly believe the result will be rather
surprising for most.

With a bit of luck we may even see more patches like this one today.
Even if you are all too busy today, there is always next year I guess.


Thanks in advance,
  Johannes
-------------- next part --------------

Hi Johannes,

It would help if the patch had some explanation (ideally in the comments) of
what it is trying to accomplish.  If I’m reading the integer promotion
correctly, it is indicating that the pointer value for a getenv return is in the
low 4GB of the address space.  I suspect that this is unsound on platforms with
non-integer pointer representations and I don’t believe it’s correct on any
platform with ASLR.

I may be completely misunderstanding what the patch does, but without comments
it’s difficult to tell.

David
> On 1 Apr 2019, at 08:06, Johannes Doerfert via llvm-dev <llvm-dev at
lists.llvm.org> wrote:
> 
> To this day, we still do too little when it comes to optimizing well
> known library calls.
> 
> Given that various libraries, especially the C/C++ standard library, are
> relatively clear defined, and LLVM has all the infrastructure already in
> place, e.g., SimplifyLibCalls.cpp, it seems odd that we still miss so
> many optimization opportunities.
> 
> To show how easy it is, and how much impact it can have, I crafted a
> very simple, yet very effective patch which will hopefully only be the
> first of its kind.
> 
> The attached twelve line addition to SimplifyLibCalls.cpp provides
> subsequent passes with a better understanding of the "getenv"
function.
> 
> This function was chosen to showcase the enormous impact well placed
> information can have on real world software, including LLVM itself.
> 
> While you could take my word for it, I would encourage you to try it out
> yourself. Apply the patch and create *a new build* of LLVM to compare
> against your existing one. I firmly believe the result will be rather
> surprising for most.
> 
> With a bit of luck we may even see more patches like this one today.
> Even if you are all too busy today, there is always next year I guess.
> 
> 
> Thanks in advance,
>  Johannes
>
<0001-LibCalls-Improve-optimizations-for-getenv-library-ca.patch>_______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

I suspect that your understanding of the patch will improve if you pay careful
attention to the date of the submission.

-----Original Message-----
From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf Of David
Chisnall via llvm-dev
Sent: Monday, April 1, 2019 4:05
To: Johannes Doerfert <johannes at jdoerfert.de>
Cc: LLVM-Dev <llvm-dev at lists.llvm.org>
Subject: Re: [llvm-dev] Today is the last day of mediocre library call
optimizations

Hi Johannes,

It would help if the patch had some explanation (ideally in the comments) of
what it is trying to accomplish.  If I’m reading the integer promotion
correctly, it is indicating that the pointer value for a getenv return is in the
low 4GB of the address space.  I suspect that this is unsound on platforms with
non-integer pointer representations and I don’t believe it’s correct on any
platform with ASLR.

I may be completely misunderstanding what the patch does, but without comments
it’s difficult to tell.

David
> On 1 Apr 2019, at 08:06, Johannes Doerfert via llvm-dev <llvm-dev at
lists.llvm.org> wrote:
> 
> To this day, we still do too little when it comes to optimizing well 
> known library calls.
> 
> Given that various libraries, especially the C/C++ standard library, 
> are relatively clear defined, and LLVM has all the infrastructure 
> already in place, e.g., SimplifyLibCalls.cpp, it seems odd that we 
> still miss so many optimization opportunities.
> 
> To show how easy it is, and how much impact it can have, I crafted a 
> very simple, yet very effective patch which will hopefully only be the 
> first of its kind.
> 
> The attached twelve line addition to SimplifyLibCalls.cpp provides 
> subsequent passes with a better understanding of the "getenv"
function.
> 
> This function was chosen to showcase the enormous impact well placed 
> information can have on real world software, including LLVM itself.
> 
> While you could take my word for it, I would encourage you to try it 
> out yourself. Apply the patch and create *a new build* of LLVM to 
> compare against your existing one. I firmly believe the result will be 
> rather surprising for most.
> 
> With a bit of luck we may even see more patches like this one today.
> Even if you are all too busy today, there is always next year I guess.
> 
> 
> Thanks in advance,
>  Johannes
>
<0001-LibCalls-Improve-optimizations-for-getenv-library-ca.patch>_____
> __________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
_______________________________________________
LLVM Developers mailing list
llvm-dev at lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

Hi David,

thanks for your input!

I was actually trying to eliminate only one value from the set of
possible results, namely -1, though it was pretty late and I might have
overdone it.

Sorry for any confusion this might have caused.

Cheers,
  Johannes


On 04/01, David Chisnall via llvm-dev wrote:
> Hi Johannes,
> 
> It would help if the patch had some explanation (ideally in the comments)
of what it is trying to accomplish.  If I’m reading the integer promotion
correctly, it is indicating that the pointer value for a getenv return is in the
low 4GB of the address space.  I suspect that this is unsound on platforms with
non-integer pointer representations and I don’t believe it’s correct on any
platform with ASLR.
> 
> I may be completely misunderstanding what the patch does, but without
comments it’s difficult to tell.
> 
> David
> 
> > On 1 Apr 2019, at 08:06, Johannes Doerfert via llvm-dev <llvm-dev
at lists.llvm.org> wrote:
> > 
> > To this day, we still do too little when it comes to optimizing well
> > known library calls.
> > 
> > Given that various libraries, especially the C/C++ standard library,
are
> > relatively clear defined, and LLVM has all the infrastructure already
in
> > place, e.g., SimplifyLibCalls.cpp, it seems odd that we still miss so
> > many optimization opportunities.
> > 
> > To show how easy it is, and how much impact it can have, I crafted a
> > very simple, yet very effective patch which will hopefully only be the
> > first of its kind.
> > 
> > The attached twelve line addition to SimplifyLibCalls.cpp provides
> > subsequent passes with a better understanding of the
"getenv" function.
> > 
> > This function was chosen to showcase the enormous impact well placed
> > information can have on real world software, including LLVM itself.
> > 
> > While you could take my word for it, I would encourage you to try it
out
> > yourself. Apply the patch and create *a new build* of LLVM to compare
> > against your existing one. I firmly believe the result will be rather
> > surprising for most.
> > 
> > With a bit of luck we may even see more patches like this one today.
> > Even if you are all too busy today, there is always next year I guess.
> > 
> > 
> > Thanks in advance,
> >  Johannes
> >
<0001-LibCalls-Improve-optimizations-for-getenv-library-ca.patch>_______________________________________________
> > LLVM Developers mailing list
> > llvm-dev at lists.llvm.org
> > https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
> 
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
-- 

Johannes Doerfert
Researcher

Argonne National Laboratory
Lemont, IL 60439, USA

jdoerfert at anl.gov
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20190401/9ecd4cc0/attachment.sig>