<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<br>
<br>
<div class="moz-cite-prefix">On 03/22/2016 06:50 PM, Ehsan Amiri
wrote:<br>
</div>
<blockquote
cite="mid:CAJ6ibVerWj+yLh5E8cPVocTCP6-MG3tTqptUomZUqftaSu_XSQ@mail.gmail.com"
type="cite">
<div dir="ltr"><br>
<div class="gmail_extra"><br>
<div class="gmail_quote">On Tue, Mar 22, 2016 at 6:42 PM,
Philip Reames <span dir="ltr"><<a moz-do-not-send="true"
href="mailto:listmail@philipreames.com" target="_blank">listmail@philipreames.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF"><span class=""> <br>
<br>
<div>On 03/22/2016 02:44 PM, Ehsan Amiri wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">
<div>
<div>Thanks. <br>
<br>
</div>
<b>Phillip, </b>As Hal said I do not think (1)
is a very large item. Please let me know if I am
mistaken. <br>
</div>
</div>
</blockquote>
</span> I have no specific reason to believe it will be
a large amount of work, but prior experience tells me
changes to canonical form have a tendency of exposing
unexpected issues. To be clear, I am supportive of you
implementing solution 1. <br>
<div>
<div class="h5">
<blockquote type="cite">
<div dir="ltr"><br>
</div>
</blockquote>
</div>
</div>
</div>
</blockquote>
<div><br>
</div>
<div>Thanks Phillip. Do you mean exposing bugs that were
unknown before? or something else?<br>
</div>
<div><br>
If the problem is that some transformations will start to
have problems because they do not know how to deal with
the new canonical form, that's alarming. If the chances of
exposing such problem is not too high, then we can
possibly go ahead with (1) and fallback to (2) if (1)
starts to be complicated. But if the risk is too high,
then we may want to prefer (2) to (1).<br>
</div>
</div>
</div>
</div>
</blockquote>
Most are not correctness bugs, but performance bugs. Later passes
(particular CGP and later) do not do well when presented arbitrary
non-canonical IR. They won't crash, but they may not be as
effective as expected and may miss obvious performance wins. When
you change what canonical is, you sometimes miss the existing sweat
spot and have to adjust the code to handle the new canonical form.
<br>
<br>
My suggestion would be to implement your change, run a reasonable
set of performance tests, fix any problems, and iterate. Just don't
be surprised if what seems like a simple patch snowballs into a
series of mostly minor patches. I'm not trying to warn you off or
scare you; I just want to make sure you have reasonable expectations
going in. <br>
<blockquote
cite="mid:CAJ6ibVerWj+yLh5E8cPVocTCP6-MG3tTqptUomZUqftaSu_XSQ@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<div><br>
</div>
<div>Any suggestions?<br>
<br>
</div>
<div><br>
<br>
<br>
<br>
<br>
</div>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF">
<div>
<div class="h5">
<blockquote type="cite">
<div dir="ltr"> <b>David </b>I think (1) is more
inline with typeless pointer work than (2).
Contributing to typeless pointer work will be
great, but given its unknown time frame we
cannot stop fixing existing problems. Of course,
we should follow an approach consistent with the
long-term solution.<br>
</div>
<div class="gmail_extra"><br>
<div class="gmail_quote">On Tue, Mar 22, 2016 at
5:30 PM, David Blaikie <span dir="ltr"><<a
moz-do-not-send="true"
href="mailto:dblaikie@gmail.com"
target="_blank"><a class="moz-txt-link-abbreviated" href="mailto:dblaikie@gmail.com">dblaikie@gmail.com</a></a>></span>
wrote:<br>
<blockquote class="gmail_quote"
style="margin:0 0 0 .8ex;border-left:1px
#ccc solid;padding-left:1ex">
<div dir="ltr"><br>
<div class="gmail_extra"><br>
<div class="gmail_quote"><span>On Tue,
Mar 22, 2016 at 1:41 PM, Mehdi Amini
<span dir="ltr"><<a
moz-do-not-send="true"
href="mailto:mehdi.amini@apple.com"
target="_blank"><a class="moz-txt-link-abbreviated" href="mailto:mehdi.amini@apple.com">mehdi.amini@apple.com</a></a>></span>
wrote:<br>
<blockquote class="gmail_quote"
style="margin:0 0 0
.8ex;border-left:1px #ccc
solid;padding-left:1ex">
<div style="word-wrap:break-word">Sorry
I should have been more clear
(writing to many email in
parallel)
<div><br>
</div>
<div>You're right. I was adding
a +1 to you here.
<div><br>
</div>
<div>Especially I wrote
"unless there is an
acknowledgement that
typeless pointers won't be
there before a couple of
years" with the PassManager
in mind, and I was expecting
from David some good
indication of a timeframe
for the typeless pointers.</div>
<div>If the typeless pointer
work is stalled or if it is
not planned for LLVM 3.9,</div>
</div>
</div>
</blockquote>
<div><br>
</div>
</span>
<div>It's neither stalled nor planned,
as such.</div>
<span>
<div> </div>
<blockquote class="gmail_quote"
style="margin:0 0 0
.8ex;border-left:1px #ccc
solid;padding-left:1ex">
<div style="word-wrap:break-word">
<div>
<div> I agree with Philip to
not block anything.</div>
</div>
</div>
</blockquote>
<div><br>
</div>
</span>
<div>All I'm suggesting is that if
there are people who want to fix
these bugs, I'd really appreciate
them helping out on the typeless
pointer work - it's totally
parallelizable/shardable/shareable
work & the project as a whole
seemed to agree it was the right
direction. Why not just get it done?<br>
<br>
The Pass Manager work is a bit
different & harder to share at
certain points (I don't tihnk
there's ever been a point at which
someone could ask me "what can I do
to help with the typeless pointer
work" I couldn't've given some
pretty large areas I wasn't anywhere
near touching that they could've
gotten their teeth into) - I think
it's reaching the point where
multiple passes can be ported
independently & seen some work
like that in Polly, etc. So at this
point it seems like if people want
to address the issues the new pass
manager is aimed at addressing, they
could pitch in on that effort.<br>
<br>
That said, I'm not in a position
(nor would I do so, even if I were)
to block other patches, just to
encourage people to help out on the
bigger efforts in whatever way they
can (either directly, or indirectly
through ensuring stopgaps/new work
is done in a way that makes that
future work easier (where it's
reasonable to judge what might be
easier or harder, etc), etc)<br>
<br>
- Dave</div>
<div>
<div>
<div> </div>
<blockquote class="gmail_quote"
style="margin:0 0 0
.8ex;border-left:1px #ccc
solid;padding-left:1ex">
<div
style="word-wrap:break-word">
<div><span><font
color="#888888">
<div><br>
</div>
-- </font></span></div>
<div><span><font
color="#888888">Mehdi</font></span>
<div>
<div><br>
<div><br>
<div>
<blockquote
type="cite">
<div>On Mar 22,
2016, at 1:37
PM, Philip
Reames <<a
moz-do-not-send="true"
href="mailto:listmail@philipreames.com" target="_blank"><a class="moz-txt-link-abbreviated" href="mailto:listmail@philipreames.com">listmail@philipreames.com</a></a>>
wrote:</div>
<br>
<div>
<div
text="#000000"
bgcolor="#FFFFFF"> But not what David was stating, unless I misread? I
was
specifically
responding to
David's
wording:<br>
"If we're
talking about
making an
optimization
able to ignore
the bitcast
instructions -
yes, that work
is unnecessary
& perhaps
questionable
given the
typeless
pointer work.
Not outright
off limits,
but the same
time might be
better
invested in
moving
typeless
pointers
forward if the
contributor is
so
inclined/able
to shift in
that
direction."<br>
<br>
Both "perhaps
questionable"
and "not
outright off
limits" seem
to strongly
imply such
work should be
discouraged.
I disagree
with that view
which is why I
wrote my
response.<br>
<br>
Philip<br>
<br>
<div>On
03/22/2016
01:34 PM,
Mehdi Amini
wrote:<br>
</div>
<blockquote
type="cite">
This is
roughly what I
wrote...
<div><br>
<div>
<blockquote
type="cite">
<div>On Mar
22, 2016, at
1:31 PM,
Philip Reames
<<a
moz-do-not-send="true"
href="mailto:listmail@philipreames.com" target="_blank"><a class="moz-txt-link-abbreviated" href="mailto:listmail@philipreames.com">listmail@philipreames.com</a></a>>
wrote:</div>
<br>
<div>
<div
text="#000000"
bgcolor="#FFFFFF"> I feel very strongly that blocking work on making
optimization
bitcast-ignorant
on the
typeless
pointer work
would be a
major
mistake.
Unless we
expected the
typeless
pointer work
to be
concluded
within the
near term (say
3-6 months
maximum), we
should not
block any
development
which would be
accepted in
the typeless
pointer work
wasn't
planned. <br>
<br>
In my view,
this is one of
the largest
mistakes we've
made with the
pass manager
work, it has
seriously cost
us, and I
don't want to
see it
happening
again. <br>
<br>
Philip<br>
<br>
<div>On
03/22/2016
01:09 PM,
David Blaikie
wrote:<br>
</div>
<blockquote
type="cite">
<div dir="ltr">Ultimately
everything is
going to be
made to not
rely on the
types of
pointers -
that's nearly
equivalent to
bitcast-ignorant
(the
difference
being that the
presence of an
extra
instruction
(the bitcast)
might trip up
some
optimizations
- but the
presence of
the /type/
information
implied by the
bitcast should
not trip up or
be necessary
for
optimizations
(two sides of
the same
coin))<br>
<br>
If we're
talking about
making an
optimization
able to ignore
the bitcast
instructions -
yes, that work
is unnecessary
& perhaps
questionable
given the
typeless
pointer work.
Not outright
off limits,
but the same
time might be
better
invested in
moving
typeless
pointers
forward if the
contributor is
so
inclined/able
to shift in
that
direction.<br>
<br>
But if we're
talking about
the work to
make the
optimization
not use the
type of
pointers as a
crutch - that
work is a
necessary
precursor to
the typeless
pointer work
and would be
most welcome.<br>
<br>
- David</div>
<div
class="gmail_extra"><br>
<div
class="gmail_quote">On
Tue, Mar 22,
2016 at 12:39
PM, Mehdi
Amini <span
dir="ltr"><<a
moz-do-not-send="true" href="mailto:mehdi.amini@apple.com"
target="_blank"><a class="moz-txt-link-abbreviated" href="mailto:mehdi.amini@apple.com">mehdi.amini@apple.com</a></a>></span>
wrote:<br>
<blockquote
class="gmail_quote"
style="margin:0
0 0
.8ex;border-left:1px
#ccc
solid;padding-left:1ex">
<div
style="word-wrap:break-word">I
don't really
mind, but the
intermediate
stage will not
be very nice:
that a lot of
code / tests
that needs to
be written
with bitcast,
and all of
that while
they are
deemed to
disappear. The
added value
isn't clear to
me considering
the added
work. I'm not
sure it
wouldn't add
more work for
all the
cleanup
required by
the "typeless
pointer", but
I'm not sure
what's
involved here
and if David
thinks the
intermediate
steps of
handling bit
casts
everywhere is
not making it
harder I'm
fine with it.<span><font
color="#888888">
<div><br>
</div>
<div>-- </div>
<div>Mehdi</div>
</font></span>
<div>
<div>
<div><br>
<div>
<blockquote
type="cite">
<div>On Mar
22, 2016, at
12:36 PM,
Philip Reames
<<a
moz-do-not-send="true"
href="mailto:listmail@philipreames.com" target="_blank"><a class="moz-txt-link-abbreviated" href="mailto:listmail@philipreames.com">listmail@philipreames.com</a></a>>
wrote:</div>
<br>
<div>
<div
text="#000000"
bgcolor="#FFFFFF"> I'd phrase this differently: being pointer-bitcast
agnostic is a
step towards
support
typeless
pointers. :)
We can either
become bitcast
agnostic all
in one big
change or
incrementally.
Personally,
I'd prefer the
later since it
reduces the
risk
associated
with enabling
typeless
pointers in
the end.<br>
<br>
Philip<br>
<br>
<div>On
03/22/2016
12:16 PM,
Mehdi Amini
via llvm-dev
wrote:<br>
</div>
<blockquote
type="cite"> I
don't know
enough about
the tradeoff
for 1, but 2
seems like a
bandaid for
something that
is not a
correctness
issue neither
a regression.
I'm not sure
it justifies
"bandaid
patches" while
there is a
clear path
forward, i.e.
typeless
pointers,
unless there
is an
acknowledgement
that typeless
pointers won't
be there
before a
couple of
years.
<div>
<div><br>
</div>
<div>-- </div>
<div>Mehdi</div>
<div><br>
<div>
<div>
<blockquote
type="cite">
<div>On Mar
22, 2016, at
11:32 AM,
Ehsan Amiri
<<a
moz-do-not-send="true"
href="mailto:ehsanamiri@gmail.com" target="_blank"><a class="moz-txt-link-abbreviated" href="mailto:ehsanamiri@gmail.com">ehsanamiri@gmail.com</a></a>>
wrote:</div>
<br>
<div>
<div dir="ltr">
<div>
<div>
<div>Back to
the discussion
on the RFC, I
still see some
advantage in
following the
proposed
solution. I
see two paths
forward:<br>
<br>
</div>
1- Change
canonical
form, possibly
lower memcpy
to non-integer
load and store
in
InstCombine.
Then teach the
backends to
convert that
to integer
load and store
if that is
more
profitable.
Notice that we
are talking
about loads
that have no
use other than
store. So it
is a fairly
simple change
in the
backends.<br>
<br>
</div>
2- Do not
change the
canonical
form. Then for
this bug, we
need to teach
select
speculation to
see through
bitcasts. We
will probably
need to teach
other
optimizations
to see though
bitcasts in
the future as
problems are
uncovered.
That is until
typeless
pointer work
is complete.
Once the
typeless
pointer work
is complete,
we have some
extra code in
each
optimization
for seeing
through
bitcasts which
is possibly no
longer needed.<br>
<br>
</div>
<div>Based on
this I think
(1) is the
right thing to
do. But there
might be other
reasons for
the current
canonical form
that I am not
aware of.
Please let me
know what you
think.<br>
<br>
</div>
<div>Thanks<br>
</div>
Ehsan<br>
</div>
<div
class="gmail_extra"><br>
<div
class="gmail_quote">On
Wed, Mar 16,
2016 at 2:13
PM, David
Blaikie <span
dir="ltr"><<a
moz-do-not-send="true" href="mailto:dblaikie@gmail.com" target="_blank"><a class="moz-txt-link-abbreviated" href="mailto:dblaikie@gmail.com">dblaikie@gmail.com</a></a>></span>
wrote:<br>
<blockquote
class="gmail_quote"
style="margin:0
0 0
.8ex;border-left:1px
#ccc
solid;padding-left:1ex">
<div dir="ltr"><br>
<div
class="gmail_extra"><br>
<div
class="gmail_quote"><span>On
Wed, Mar 16,
2016 at 11:00
AM, Ehsan
Amiri <span
dir="ltr"><<a
moz-do-not-send="true" href="mailto:ehsanamiri@gmail.com"
target="_blank"><a class="moz-txt-link-abbreviated" href="mailto:ehsanamiri@gmail.com">ehsanamiri@gmail.com</a></a>></span>
wrote:<br>
<blockquote
class="gmail_quote"
style="margin:0
0 0
.8ex;border-left:1px
#ccc
solid;padding-left:1ex">
<div dir="ltr">
<div>
<div>
<div>David,<br>
<br>
</div>
Could you give
us an update
on the status
of typeless
pointer work?
How much work
is left and
when you think
it might be
ready?<br>
</div>
</div>
</div>
</blockquote>
<div><br>
</div>
</span>
<div>It's a
bit of an
onion peel,
really - since
it will
eventually
involve
generalizing/fixing
every
optimization
that's
currently
leaning on
typed pointers
to keep the
performance
while removing
the crutch
they're
currently
leaning on.
(in cases
where bitcasts
are literally
just getting
in the way,
those won't
require
cleaning up
& should
just become
"free
performance
wins" once we
remove them,
though)<br>
<br>
At the moment
we can
roundtrip
every LLVM IR
test case
through
bitcode and
textual IR
(reading/writing
both formats)
while using
only a narrow
whitelist of
places that
request the
type of a
pointer
(things like
the verifier,
the
parser/printer
where it
actually needs
the typed
pointer to
verify it
matches the
explicit type,
etc).<br>
<br>
The next thing
on the list is
probably
figuring out
the
byval/inalloca
representation
(add an
explicit
pointee type?
just make the
number of
bytes explicit
with no type
information?).<br>
<br>
Then start
migrating
optimizations
over - doing
the same sort
of testing I
did for the
IR/bitcode
roundtripping
- assert that
the pointee
type is not
accessed,
whitelist
places that
need it until
the bitcasts
go away, fix
anything
else... it'll
still be a
fair bit of
work & I
don't really
know how much.
It should
parallelize
pretty well
(doing any of
this work is
really
helpful, each
optimization
is
indepednent,
etc) if anyone
wants to/is
able to help.<br>
<br>
- Dave</div>
<div>
<div>
<div> </div>
<blockquote
class="gmail_quote"
style="margin:0
0 0
.8ex;border-left:1px
#ccc
solid;padding-left:1ex">
<div dir="ltr">
<div>
<div><br>
</div>
Thanks<span><font
color="#888888"><br>
</font></span></div>
<span><font
color="#888888">Ehsan<br>
<br>
</font></span></div>
<div>
<div>
<div
class="gmail_extra"><br>
<div
class="gmail_quote">On
Wed, Mar 16,
2016 at 1:12
PM, David
Blaikie <span
dir="ltr"><<a
moz-do-not-send="true" href="mailto:dblaikie@gmail.com" target="_blank"><a class="moz-txt-link-abbreviated" href="mailto:dblaikie@gmail.com">dblaikie@gmail.com</a></a>></span>
wrote:<br>
<blockquote
class="gmail_quote"
style="margin:0
0 0
.8ex;border-left:1px
#ccc
solid;padding-left:1ex">
<div dir="ltr"><br>
<div
class="gmail_extra"><br>
<div
class="gmail_quote"><span>On
Wed, Mar 16,
2016 at 8:34
AM, Mehdi
Amini via
llvm-dev <span
dir="ltr"><<a
moz-do-not-send="true" href="mailto:llvm-dev@lists.llvm.org"
target="_blank"><a class="moz-txt-link-abbreviated" href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a></a>></span>
wrote:<br>
<blockquote
class="gmail_quote"
style="margin:0
0 0
.8ex;border-left:1px
#ccc
solid;padding-left:1ex">
<div
style="word-wrap:break-word">Hi,
<div><br>
</div>
<div>How do it
interact with
the "typeless
pointers"
work?</div>
</div>
</blockquote>
<div><br>
</div>
</span>
<div>Right -
the goal of
the typeless
pointer work
is to fix all
these bugs
related to
"didn't look
through
bitcasts" in
optimizations.
Sometimes
that's going
to mean more
work (because
the code is
leaning on the
absence of
bitcasts &
the presence
of convenient
(but not
guaranteed)
type
information to
inform
optimization
decisions) but
if we remove
typed pointers
while keeping
optimization
quality in the
cases we have
today, then we
should've also
fixed the
cases that
were broken
because the
type
information
didn't end up
aligning to
produce the
optimal
output.<br>
<br>
& I know
I've been off
the typeless
pointer stuff
for a few
months working
on llvm-dwp -
but happy for
any help (the
next immediate
piece is
probably
figuring out
teh right
representation
for byval and
inalloca -
there were
some code
reviews sent
out for that
that I'll need
to come back
around to -
but also any
optimizations
people want to
help
rework/improve
would be great
too & I
can provide
some
techniques/tools
to help people
approach
those)<br>
<br>
- Dave</div>
<div>
<div>
<div> </div>
<blockquote
class="gmail_quote"
style="margin:0
0 0
.8ex;border-left:1px
#ccc
solid;padding-left:1ex">
<div
style="word-wrap:break-word">
<div><br>
</div>
<div>Thanks,</div>
<div><br>
</div>
<div>-- </div>
<div>Mehdi</div>
<div><br>
<div>
<blockquote
type="cite">
<div>
<div>
<div>On Mar
16, 2016, at
6:41 AM, Ehsan
Amiri via
llvm-dev <<a
moz-do-not-send="true" href="mailto:llvm-dev@lists.llvm.org"
target="_blank"><a class="moz-txt-link-abbreviated" href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a></a>>
wrote:</div>
<br>
</div>
</div>
<div>
<div>
<div>
<div dir="ltr">===
PROBLEM ===
(See this bug
<a
moz-do-not-send="true"
href="https://llvm.org/bugs/show_bug.cgi?id=26445" target="_blank"><a class="moz-txt-link-freetext" href="https://llvm.org/bugs/show_bug.cgi?id=26445">https://llvm.org/bugs/show_bug.cgi?id=26445</a></a>)<br>
<br>
IR contains
code for
loading a
float from
float * and
storing it to
a float *
address. After
canonicalization
of load in
InstCombine
[1], new
bitcasts are
added to the
IR (see bottom
of the email
for code
samples). This
prevents
select
speculation in
SROA to work.
Also after
SROA we have
bitcasts from
int32 to
float.
(Whereas
originally
after
instCombine,
bitcasts are
only done on
pointer
types).<br>
<br>
=== PROPOSED
SOLUTION===<br>
<br>
[1] implies
that we need
load
canonicalization
when we load a
value only to
store it
again. The
reason is to
avoid
generating
slightly
different code
(due to
different ways
of adding
bitcasts), in
different
situations. In
all examples
presented in
[1] there is a
non-zero
number of
bitcasts. I
think when we
load a value
of type T from
a T* address
and store it
as a type T
value to one
or more T*
address (and
there is no
other use or
store), we can
redefine
canonical form
to mean there
should not be
any bitcasts.
So we still
have a
canonical
form, but its
definition is
slightly
different.<br>
<br>
=== REASONS
FOR /
AGAINST===<br>
<br>
Hal Finkel
warns that
while this may
be useful for
power pc, this
may hurt more
than one other
platform and
become a very
large project.
Despite this
he is fine
with bringing
up the issue
to the mailing
list to get
feedback,
mostly because
this seems
inline with
our future
direction of
having a
unique type
for all
pointers.
(Hal please
correct me if
I
misunderstood
your comment)<br>
<br>
This is a much
simpler fix
compared to
alternatives.
(ignoring
potential
regressions)<br>
<br>
===
ALTERNATIVE
SOLUTION ===<br>
<br>
Fix select
speculation in
SROA to see
through
bitcasts.
Handle
remaining
bitcasts
during code
gen. Other
alternative
solutions are
welcome.<br>
<br>
Should I
implement the
proposed
solution or is
it too risky?
I understand
that we may
need to undo
it if it
breaks too
many things.
Comments are
welcome.<br>
<br>
<br>
[1] <a
moz-do-not-send="true"
href="http://lists.llvm.org/pipermail/llvm-dev/2015-January/080956.html"
target="_blank"><a class="moz-txt-link-freetext" href="http://lists.llvm.org/pipermail/llvm-dev/2015-January/080956.html">http://lists.llvm.org/pipermail/llvm-dev/2015-January/080956.html</a></a>
r226781 git
commit id:
b778cbc0c8<br>
<br>
<br>
<br>
Code Samples
(only relevant
part is
copied):<br>
<br>
--------------------
Before
Canonicalization
(contains call
to std::max):
--------------------
<br>
entry:<br>
%max_value =
alloca float,
align 4<br>
%1 = load
float, float*
%input, align
4, !tbaa !1<br>
store float
%1, float*
%max_value,
align 4, !tbaa
!1<br>
<br>
for.body:<br>
%call = call
dereferenceable(4)
float*
@_ZSt3maxIfERKT_S2_S2_(float*
dereferenceable(4)
%max_value,
float*
dereferenceable(4)
%arrayidx1)<br>
%3 = load
float, float*
%call, align
4, !tbaa !1<br>
store float
%3, float*
%max_value,
align 4, !tbaa
!1<br>
<br>
--------------------
After
Canonicalization
(contains call
to
std::max):--------------------
<br>
<br>
entry:<br>
%max_value =
alloca float,
align 4<br>
%1 = bitcast
float* %input
to i32*<br>
%2 = load
i32, i32* %1,
align 4, !tbaa
!1<br>
%3 = bitcast
float*
%max_value to
i32*<br>
store i32
%2, i32* %3,
align 4, !tbaa
!1<br>
<br>
for.body:<br>
%call = call
dereferenceable(4)
float*
@_ZSt3maxIfERKT_S2_S2_(float*
nonnull
dereferenceable(4)
%max_value,
float*
dereferenceable(4)
%arrayidx1)<br>
%5 = bitcast
float* %call
to i32*<br>
%6 = load
i32, i32* %5,
align 4, !tbaa
!1<br>
%7 = bitcast
float*
%max_value to
i32*<br>
store i32
%6, i32* %7,
align 4, !tbaa
!1<br>
<br>
--------------------
After SROA
(the call to
std::max is
inlined
now):--------------------
<br>
entry:<br>
%max_value.sroa.0
= alloca i32<br>
%0 = bitcast
float* %input
to i32*<br>
%1 = load
i32, i32* %0,
align 4, !tbaa
!1<br>
store i32
%1, i32*
%max_value.sroa.0<br>
<br>
for.body: <br>
%max_value.sroa.0.0.max_value.sroa.0.0.6
= load i32,
i32*
%max_value.sroa.0<br>
%3 = bitcast
i32
%max_value.sroa.0.0.max_value.sroa.0.0.6
to float<br>
%max_value.sroa.0.0.max_value.sroa_cast8
= bitcast i32*
%max_value.sroa.0
to float*<br>
%__b.__a.i =
select i1
%cmp.i, float*
%arrayidx1,
float*
%max_value.sroa.0.0.max_value.sroa_cast8<br>
%5 = bitcast
float*
%__b.__a.i to
i32*<br>
%6 = load
i32, i32* %5,
align 4, !tbaa
!1<br>
store i32
%6, i32*
%max_value.sroa.0<br>
<br>
--------------------
After SROA
when
Canonicalization
is turned
off--------------------
<br>
entry:<br>
%0 = load
float, float*
%input, align
4, !tbaa !1<br>
<br>
for.cond:
; preds =
%for.body,
%entry<br>
%max_value.0
= phi float [
%0, %entry ],
[
%.sroa.speculated,
%for.body ]<br>
<br>
for.body:<br>
%1 = load
float, float*
%arrayidx1,
align 4, !tbaa
!1<br>
%cmp.i =
fcmp olt float
%max_value.0,
%1<br>
%.sroa.speculate.load.true
= load float,
float*
%arrayidx1,
align 4, !tbaa
!1<br>
%.sroa.speculated
= select i1
%cmp.i, float
%.sroa.speculate.load.true,
float
%max_value.0<br>
</div>
</div>
</div>
_______________________________________________<br>
LLVM
Developers
mailing list<br>
<a
moz-do-not-send="true"
href="mailto:llvm-dev@lists.llvm.org" target="_blank"><a class="moz-txt-link-abbreviated" href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a></a><br>
<a
moz-do-not-send="true"
href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev"
target="_blank"><a class="moz-txt-link-freetext" href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a></a><br>
</div>
</blockquote>
</div>
<br>
</div>
</div>
<br>
_______________________________________________<br>
LLVM
Developers
mailing list<br>
<a
moz-do-not-send="true"
href="mailto:llvm-dev@lists.llvm.org" target="_blank"><a class="moz-txt-link-abbreviated" href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a></a><br>
<a
moz-do-not-send="true"
href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev"
target="_blank"><a class="moz-txt-link-freetext" href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a></a><br>
<br>
</blockquote>
</div>
</div>
</div>
<br>
</div>
</div>
</blockquote>
</div>
<br>
</div>
</div>
</div>
</blockquote>
</div>
</div>
</div>
<br>
</div>
</div>
</blockquote>
</div>
<br>
</div>
</div>
</blockquote>
</div>
<br>
</div>
</div>
</div>
<br>
<fieldset></fieldset>
<br>
<pre>_______________________________________________
LLVM Developers mailing list
<a moz-do-not-send="true" href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>
<a moz-do-not-send="true" href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a>
</pre>
</blockquote>
<br>
</div>
</div>
</blockquote>
</div>
<br>
</div>
</div>
</div>
</div>
</blockquote>
</div>
<br>
</div>
</blockquote>
<br>
</div>
</div>
</blockquote>
</div>
<br>
</div>
</blockquote>
<br>
</div>
</div>
</blockquote>
</div>
<br>
</div>
</div>
</div>
</div>
</div>
</blockquote>
</div>
</div>
</div>
<br>
</div>
</div>
</blockquote>
</div>
<br>
</div>
</blockquote>
<br>
</div>
</div>
</div>
</blockquote>
</div>
<br>
</div>
</div>
</blockquote>
<br>
</body>
</html>