[LLVMdev] -inline odd behavior

[Ryan Taylor]

Yes, that makes sense but not if it isn't doing anything with it. If it
doesn't inline it then it shouldn't be modifying it, or at least that's
what makes sense to me. If part of it's job is to delete functions that
were created "dead" by some other opt, then shouldn't that opt be deleting
the functions it makes dead?

I guess I don't see the point in deleting functions (even dead ones) that
it doesn't touch, what's the point? Why bother to even compile those
functions then? It's not like clang or llvm-gcc gives me an empty function,
only "-inline"?

On Fri, Feb 10, 2012 at 3:10 PM, Eli Friedman <eli.friedman at gmail.com>wrote:

> On Fri, Feb 10, 2012 at 2:47 PM, Ryan Taylor <ryta1203 at gmail.com> wrote:
> > Seems like bad behavior to just decide to delete the function, no? Why
> not
> > just ignore it then and output the input?
>
> Deleting dead functions is part of the functionality of -inline.
>
> -Eli
>
> >
> >
> > On Fri, Feb 10, 2012 at 2:43 PM, Eli Friedman <eli.friedman at gmail.com>
> > wrote:
> >>
> >> On Fri, Feb 10, 2012 at 2:38 PM, Ryan Taylor <ryta1203 at gmail.com>
> wrote:
> >> > I have some code that has one function and if I use the-inline on it
> >> > then
> >> > these opts eliminate the entire function (which is the entire file).
> >> >
> >> > Bugpoint produces bugpoint-reduced-simplified.bc, but when I then run
> >> > "opt
> >> > bugpoint-reduced-simplified.bc -inline" I get nothing, file get
> emptied.
> >> >
> >> > It doesn't crash or assert. I have attached a test case.
> >>
> >> Your function has internal linkage and no uses; therefore, your .ll
> >> file is equivalent to the empty .ll file.
> >>
> >> -Eli
> >
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20120210/90935769/attachment.html>