LLD: Move RoundTrip tests behind a flag
Shankar Easwaran
shankare at codeaurora.org
Wed Mar 19 16:56:12 PDT 2014
LGTM.
On 3/19/2014 6:38 PM, Rui Ueyama wrote:
> Looks like we agreed that this should be enabled only when some
> environment variable (maybe LLD_ENABLE_ROUNDTRIP_TEST?) is set, ok?
>
>
> On Wed, Mar 19, 2014 at 4:31 PM, Shankar Easwaran
> <shankare at codeaurora.org <mailto:shankare at codeaurora.org>> wrote:
>
> On 3/19/2014 5:44 PM, Nick Kledzik wrote:
>
> On Mar 19, 2014, at 3:38 PM, Rui Ueyama <ruiu at google.com
> <mailto:ruiu at google.com>> wrote:
>
> It is proved that RoundTripNative and RoundTripYAML are
> good harnesses to guarantee there's no information loss
> when an object is converted to/from native/YAML formats.
> However, it makes LLD *extremely* slow when linking
> non-toy programs.
>
> If RoundTrip tests are enabled, LLD takes about 10
> *minutes* to link itself on my Linux box. My machine is
> 3.5GHz Xeon. The result of gprof on LLD linking
> llvm-tblegen shows that 77.8% of time was consumed by
> RoundTripYAMLPass::perform() and 16.6% by
> RoundTripNativePass::perform(). It means RoundTrip tests
> are the dominant factor.
>
> I couldn't even run LLD linking LLD with profiling enabled
> because it was too slow that I couldn't wait it to finish.
>
> This is not an acceptable performance penalty even for
> debug build. I think we should move the feature behind a
> flag and enable it only for tests.
>
> Any objections?
>
> Sounds good. But, how can we set it up so that all tests
> (including tests added later) will get the round trip passes
> by default? Is there some environment variable that the LIT
> harness sets up that the driver can detect and run those
> passes by default?
>
> I like the environment variable idea too.
>
>
> --
> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
> hosted by the Linux Foundation
>
>
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by the Linux Foundation
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20140319/9abed4e6/attachment.html>
More information about the llvm-commits
mailing list