[llvm-dev] Need help with code generation

Hal Finkel via llvm-dev llvm-dev at lists.llvm.org
Tue Mar 22 13:05:44 PDT 2016 

----- Original Message -----

> From: "Rui Ueyama" <ruiu at google.com>
> To: "Hal Finkel" <hfinkel at anl.gov>
> Cc: "David Blaikie" <dblaikie at gmail.com>, "llvm-dev"
> <llvm-dev at lists.llvm.org>, "Bruce Hoult" <bruce at hoult.org>
> Sent: Tuesday, March 22, 2016 2:57:45 PM
> Subject: Re: [llvm-dev] Need help with code generation

> On Tue, Mar 22, 2016 at 8:40 PM, Hal Finkel < hfinkel at anl.gov >
> wrote:

> > > From: "Rui Ueyama" < ruiu at google.com >
> > 
> 
> > > To: "Hal Finkel" < hfinkel at anl.gov >
> > 
> 
> > > Cc: "David Blaikie" < dblaikie at gmail.com >, "llvm-dev" <
> > > llvm-dev at lists.llvm.org >, "Bruce Hoult" < bruce at hoult.org >
> > 
> 
> > > Sent: Tuesday, March 22, 2016 2:36:34 PM
> > 
> 
> > > Subject: Re: [llvm-dev] Need help with code generation
> > 
> 

> > > On Tue, Mar 22, 2016 at 7:36 PM, Rui Ueyama < ruiu at google.com >
> > > wrote:
> > 
> 

> > > > I have a question. If there is a ELF verifier function that
> > > > walks
> > > > every part of an ELF file to verify that the file is sane, and
> > > > if
> > > > you can call that before calling LLD's function, are you guys
> > > > happy
> > > > with that?
> > > 
> > 
> 
> > > I'd like to get you guys opinion on this question.
> > 
> 
> > I'll echo Rafael here. What does "sane" mean? If I define sane to
> > mean, "will not cause lld to exhibit undefined behavior if later
> > run
> > over the same input", then this seems like the most efficient way
> > of
> > satisfying that goal (perhaps staged to avoid cache thrashing), and
> > I'd like to know how much overhead it would add to run it in lld by
> > default (even if we have an option to disable it for absolute
> > speed).
> 

> ELF is a documented file format so if you are not sure if something
> should be considered valid, you can take a look at the spec to
> determine whether it is valid or not. File validity is an
> independent concept from LLD and I think we can determine it
> according to the spec.
I understand your point. However, how does this compare in complexity to using the input to link against something trivial except that it requires all of its symbols? 

> I have a different opinion about how it could be implemented. We have
> no idea if it'd be faster if it is "embedded" to LLD, at least. And
> usually separating passes leads to cleaner and more readable code.\
Yes, but how much code would it share with lld itself? And running it as a separate pass could be considerably more expensive on large inputs. 

Thanks again, 
Hal 

> > Thanks again,
> 
> > Hal
> 

> > > > On Tue, Mar 22, 2016 at 6:39 PM, Hal Finkel via llvm-dev <
> > > > llvm-dev at lists.llvm.org > wrote:
> > > 
> > 
> 

> > > > > > From: "David Blaikie via llvm-dev" <
> > > > > > llvm-dev at lists.llvm.org
> > > > > > >
> > > > > 
> > > > 
> > > 
> > 
> 
> > > > > > To: "Rafael Espíndola" < rafael.espindola at gmail.com >
> > > > > 
> > > > 
> > > 
> > 
> 
> > > > > > Cc: "llvm-dev" < llvm-dev at lists.llvm.org >, "Bruce Hoult" <
> > > > > > bruce at hoult.org >
> > > > > 
> > > > 
> > > 
> > 
> 
> > > > > > Sent: Tuesday, March 22, 2016 10:18:03 AM
> > > > > 
> > > > 
> > > 
> > 
> 
> > > > > > Subject: Re: [llvm-dev] Need help with code generation
> > > > > 
> > > > 
> > > 
> > 
> 

> > > > > > On Tue, Mar 22, 2016 at 4:27 AM, Rafael Espíndola <
> > > > > > llvm-dev at lists.llvm.org > wrote:
> > > > > 
> > > > 
> > > 
> > 
> 

> > > > > > > > Maybe not, but it's not impossible either - browsers
> > > > > > > > manage
> > > > > > > > to
> > > > > > > > harden themselves against malicious input and they
> > > > > > > > operate
> > > > > > > > in
> > > > > > > > a
> > > > > > > > far hostile environment with many more input formats
> > > > > > > > than
> > > > > > > > we
> > > > > > > > do.
> > > > > > 
> > > > > 
> > > > 
> > > 
> > 
> 

> > > > > > > It is important to note how different they are. Both
> > > > > > > Firefox
> > > > > > > and
> > > > > > 
> > > > > 
> > > > 
> > > 
> > 
> 
> > > > > > > Chromium have people working just to try to make them
> > > > > > > more
> > > > > > > secure.
> > > > > > 
> > > > > 
> > > > 
> > > 
> > 
> 
> > > > > > > Compare that with LLVM: One week ago I pointed out that
> > > > > > > your
> > > > > > > patch
> > > > > > 
> > > > > 
> > > > 
> > > 
> > 
> 
> > > > > > > (r263521) introduces a crash. It still hasn't been
> > > > > > > reverted
> > > > > > > or
> > > > > > > even
> > > > > > 
> > > > > 
> > > > 
> > > 
> > 
> 
> > > > > > > acknowledge yet.
> > > > > > 
> > > > > 
> > > > 
> > > 
> > 
> 

> > > > > > > > I'm not trying to shift your personal goal, or to
> > > > > > > > direct
> > > > > > > > the
> > > > > > > > features that you choose to put your time into, but I
> > > > > > > > am
> > > > > > > > interested in project policy.
> > > > > > 
> > > > > 
> > > > 
> > > 
> > 
> 

> > > > > > > Why do you care about policy that is not followed? A
> > > > > > > policy
> > > > > > > saying
> > > > > > 
> > > > > 
> > > > 
> > > 
> > 
> 
> > > > > > > llvm should not crash on any input is as relevant as one
> > > > > > > that
> > > > > > > says
> > > > > > 
> > > > > 
> > > > 
> > > 
> > 
> 
> > > > > > > that clang should keep bootstrapping in under one second.
> > > > > > 
> > > > > 
> > > > 
> > > 
> > 
> 

> > > > > > It's pretty different when you say, essentially, that
> > > > > > patches
> > > > > > to
> > > > > > address these things are unlikely to be accepted. It
> > > > > > doesn't
> > > > > > seem
> > > > > > surprising that people wouldn't try to provide those
> > > > > > patches
> > > > > > and
> > > > > > would choose not to use the project if that's the expressed
> > > > > > policy
> > > > > > of the developers on the project and doesn't line up with
> > > > > > the
> > > > > > needs
> > > > > > of other people.
> > > > > 
> > > > 
> > > 
> > 
> 
> > > > > +1
> > > > 
> > > 
> > 
> 

> > > > > -Hal
> > > > 
> > > 
> > 
> 

> > > > > > > So, if we stick to reality, what we have is that lld (ELF
> > > > > > > and
> > > > > > > COFF)
> > > > > > 
> > > > > 
> > > > 
> > > 
> > 
> 
> > > > > > > are already the most reliable parts of the toolchain. If
> > > > > > > not
> > > > > > > for
> > > > > > > Rui
> > > > > > 
> > > > > 
> > > > 
> > > 
> > 
> 
> > > > > > > and I being upfront about it most people would not even
> > > > > > > know
> > > > > > > that
> > > > > > > you
> > > > > > 
> > > > > 
> > > > 
> > > 
> > 
> 
> > > > > > > could crash it. So please, just let us keep working on
> > > > > > > the
> > > > > > > most
> > > > > > 
> > > > > 
> > > > 
> > > 
> > 
> 
> > > > > > > reliable part of the toolchain.
> > > > > > 
> > > > > 
> > > > 
> > > 
> > 
> 

> > > > > > > Cheers,
> > > > > > 
> > > > > 
> > > > 
> > > 
> > 
> 
> > > > > > > Rafael
> > > > > > 
> > > > > 
> > > > 
> > > 
> > 
> 
> > > > > > > _______________________________________________
> > > > > > 
> > > > > 
> > > > 
> > > 
> > 
> 
> > > > > > > LLVM Developers mailing list
> > > > > > 
> > > > > 
> > > > 
> > > 
> > 
> 
> > > > > > > llvm-dev at lists.llvm.org
> > > > > > 
> > > > > 
> > > > 
> > > 
> > 
> 
> > > > > > > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
> > > > > > 
> > > > > 
> > > > 
> > > 
> > 
> 

> > > > > > _______________________________________________
> > > > > 
> > > > 
> > > 
> > 
> 
> > > > > > LLVM Developers mailing list
> > > > > 
> > > > 
> > > 
> > 
> 
> > > > > > llvm-dev at lists.llvm.org
> > > > > 
> > > > 
> > > 
> > 
> 
> > > > > > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
> > > > > 
> > > > 
> > > 
> > 
> 

> > > > > --
> > > > 
> > > 
> > 
> 

> > > > > Hal Finkel
> > > > 
> > > 
> > 
> 
> > > > > Assistant Computational Scientist
> > > > 
> > > 
> > 
> 
> > > > > Leadership Computing Facility
> > > > 
> > > 
> > 
> 
> > > > > Argonne National Laboratory
> > > > 
> > > 
> > 
> 

> > > > > _______________________________________________
> > > > 
> > > 
> > 
> 
> > > > > LLVM Developers mailing list
> > > > 
> > > 
> > 
> 
> > > > > llvm-dev at lists.llvm.org
> > > > 
> > > 
> > 
> 
> > > > > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
> > > > 
> > > 
> > 
> 

> > --
> 

> > Hal Finkel
> 
> > Assistant Computational Scientist
> 
> > Leadership Computing Facility
> 
> > Argonne National Laboratory
> 

-- 

Hal Finkel 
Assistant Computational Scientist 
Leadership Computing Facility 
Argonne National Laboratory 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160322/0bc86c03/attachment.html>

More information about the llvm-dev mailing list