[llvm-dev] EuroLLVM BoF session: Compilers in education
vivek pandya via llvm-dev
llvm-dev at lists.llvm.org
Tue Mar 1 10:12:00 PST 2016
*Vivek Pandya*
On Tue, Mar 1, 2016 at 11:18 PM, via llvm-dev <llvm-dev at lists.llvm.org>
wrote:
> Send llvm-dev mailing list submissions to
> llvm-dev at lists.llvm.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
> or, via email, send a message with subject or body 'help' to
> llvm-dev-request at lists.llvm.org
>
> You can reach the person managing the list at
> llvm-dev-owner at lists.llvm.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of llvm-dev digest..."
>
>
> Today's Topics:
>
> 1. EuroLLVM BoF session: Compilers in education
> (Roel Jordans via llvm-dev)
> 2. Problem with mingw32 DLL build (Chandler Carruth via llvm-dev)
> 3. Re: [GSoC 2016] Code Generation Improvements task
> (vivek pandya via llvm-dev)
> 4. Re: RFC: Add bitcode tests to test-suite
> (Mehdi Amini via llvm-dev)
> 5. Re: Compiler-RT cmake building (Alexey Samsonov via llvm-dev)
> 6. Re: Compiling for AArch64: CommandLine Error: Option
> 'aarch64-branch-relax' registered more than once!
> (Kai Nacke via llvm-dev)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Tue, 1 Mar 2016 17:27:40 +0100
> From: Roel Jordans via llvm-dev <llvm-dev at lists.llvm.org>
> To: <llvm-dev at lists.llvm.org>
> Subject: [llvm-dev] EuroLLVM BoF session: Compilers in education
> Message-ID: <56D5C2FC.40606 at tue.nl>
> Content-Type: text/plain; charset="utf-8"; format=flowed
>
> Hi all,
>
> I'm organizing a BoF session during the upcoming EuroLLVM developers
> meeting. As the subject of this message already shows, this session
> will be on compilers in education. I'm currently looking for both
> participants to the discussion and input for the actual program of the
> session. I've already got some ideas which I'll introduce below.
>
> At our university, we mostly come from a hardware and processor design
> background. In the past we managed to design all kinds of crazy
> architecture ideas and, since we could program them by hand for our
> demonstration cases, we usually assumed that compilers could just 'do
> the trick'. However, over the years we learned that this usually wasn't
> the case. Looking around for what was actually being taught in compiler
> design we found that the course at our university had been teaching
> mostly the classical frontend parts (parsing etc) and was discontinued
> several years ago. We decided it was time for us to step up and start
> teaching our students again what is and isn't possible in compilers.
> This time, also with extensions into the layers that relate more closely
> to the hardware so that the course would match our processor
> architecture backgrounds more closely.
>
> In general, the contents of this course are more or less as follows:
> - Backend organization (optimizations, lowering, scheduling, register
> allocation)
> - Code optimization (code analysis, loop optimizations, auto
> vectorization, Polly)
> - Using the compiler (writing optimizer friendly code)
> - Heterogeneous systems and high-level languages (OpenCL, OpenMP, Halide)
>
> Looking further we also found that there aren't many courses that cover
> these topics (while we think that they should be interest to the
> companies hiring our students).
>
> During this BoF, I plan to introduce the topics which we now cover in
> our course and the assignments that we give to our students to go with
> that.
>
> My long term goal is to make most of the materials for this course
> available to interested parties. One idea was to transform this into
> some kind of MOOC structure when after we get the lectures tested on our
> own students (currently there are some 70 students attending this
> course). We've already automated much of the testing and grading for
> the exercises (though improvement is still possibly there).
>
> So, my questions to you:
> - Would you be interested in attending this session?
> - For industry people:
> * what kind of skills would you like your future (or current)
> employees to have?
> * do you have any educational materials you would be willing to share?
> - For other educators: what kind of topics do you cover in your lectures?
> * would you be interested in presenting something about your approach?
> - And in general: are there any other things you think that should be
> discussed?
>
> Ok, that's it for now. I've already heard from a few people that they
> would be interested but I'd love to get some more input!
This is very great idea to make student understand and experiment with LLVM
and related technology. It would be great if this is converted in to a MOOC
and hosted on some web platform so that people like me ( remote location )
can access those materials and attempt assignments.
Sincerely,
Vivek
>
>
> Best regards,
> Roel Jordans
>
>
> ------------------------------
>
> Message: 2
> Date: Tue, 01 Mar 2016 17:01:37 +0000
> From: Chandler Carruth via llvm-dev <llvm-dev at lists.llvm.org>
> To: llvm-dev <llvm-dev at lists.llvm.org>, NAKAMURA Takumi
> <geek4civic at gmail.com>, Reid Kleckner <rnk at google.com>, Michael
> Spencer <Michael_Spencer at playstation.sony.com>
> Subject: [llvm-dev] Problem with mingw32 DLL build
> Message-ID:
> <CAGCO0Kj+rp8QcKh8sSXwYgP5-ZKnQEasEQyghu=
> h94K_tQq74A at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> Folks, there is an issue pretty buried in the commits list that I suspect
> should have wider visibility.
>
> See r262188 and subsequent discussion. To summarize: it appears that
> mingw32 was unable to correctly produce a static data member when
> instantiated as a base class. The "fix" is to then explicitly instantiate
> the base class separately from its use in a base class.
>
> I think this is unacceptable in this case because these base classes are
> intended to be the primary way that users of LLVM will define new analysis
> passes. That means we'll actually have to teach LLVM library users about
> this pattern, not just the LLVM developers. =/
>
> So my questions are:
>
> 1) Is there some more elegant way to fix this that doesn't require every
> derived class to write an explicit instantiation definition of their base
> class? If so, then the rest of my questions are moot.
>
> 2) If not, is this a problem with a native Windows 32-bit DLL build?
>
> 3) If this is a problem with the native Windows 32-bit DLL build, should we
> back out of using this pattern of CRTP injection of the static data member
> and just deal with the significant (and error prone) boiler plate? It seems
> less error prone than the alternative.
>
> 4) If this is not a problem with the native Windows 32-bit DLL, then I
> wonder how valuable it is to continue to support the conjunction of mingw32
> and a DLL build? This seems to be a really high cost to carry.
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://lists.llvm.org/pipermail/llvm-dev/attachments/20160301/6a5e4c0d/attachment-0001.html
> >
>
> ------------------------------
>
> Message: 3
> Date: Tue, 1 Mar 2016 22:56:46 +0530
> From: vivek pandya via llvm-dev <llvm-dev at lists.llvm.org>
> To: Tim Northover <t.p.northover at gmail.com>
> Cc: llvm-dev <llvm-dev at lists.llvm.org>
> Subject: Re: [llvm-dev] [GSoC 2016] Code Generation Improvements task
> Message-ID:
> <CAHYgpoL9d5mpmcd2sOfHdmKeqJKTzbdxaP3dFdUuCYSXO5x=
> yQ at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> *Vivek Pandya*
>
>
> On Tue, Mar 1, 2016 at 10:23 AM, Tim Northover <t.p.northover at gmail.com>
> wrote:
>
> > Hi Vivek,
> >
> > (Mostly responding with AArch64 hints, though anything I happen to
> > know from elsewhere too).
> >
> > On 29 February 2016 at 13:00, vivek pandya via llvm-dev
> > <llvm-dev at lists.llvm.org> wrote:
> > > 2. lib/Target/AArch64/AArch64AddressTypePromotion.cpp
> > > As far as I understand this pass promotes sign exertion for 32 bit
> > integer (
> > > address) and performs calculation on 64 bit number thus processes need
> > not
> > > switch execution mode to 32 bit.
> >
> > Switching execution mode isn't an option on AArch64 (it can only
> > happen with OS support and never happens within a single process on a
> > sane OS).
> >
> > This pass is more a matter of putting the IR in a form that precisely
> > matches the addressing modes that are actually available. AArch64 can
> > encode addresses like "base64 + sext(offset32)" into the actual
> > load/store instruction so it's advantageous to put the sext as close
> > as possible to the pointer dereference.
> >
> > I'm afraid I don't really know enough about other architectures to say
> > which could benefit. It's obviously only beneficial if they have the
> > addressing modes to support it.
> >
> > > 3. lib/Target/AArch64/AArch64PromoteConstant.cpp
> > > This pass tries to simplify aggregate data like struct of const with
> > special
> > > SIMD instructions available on the system. For example on ARM its NEON
> > > similarly other architectures have SIMD support specifically MIPS, IBM
> > > System Z, Power PC with MMX/AltiVee and x86 with Intel’s AVX.
> >
> > Possibly. It seems to rely pretty strongly on ARM's "load more than
> > you can actually use" instructions: vldN instructions can load up to 4
> > 128-bit vectors, but they can still only be used as 128-bit vectors.
> > If other targets possess similar, then they could well benefit; if
> > not, then it's probably pointless.
> >
> > > I have question regarding Target hooks. Does it means using TargetInfo
> an
> > > SubTargetInfo class and at runtime decide architecture type and based
> on
> > > that perform optimization ( i.e use target specific instructions ) ?
> >
> > I think they more normally live in TargetTransformInfo.
> >
> > > Please help me ! Am I going in right direction ? Suggest some code ,
> > > document to look for further ideas. Also if any one like to mentor me
> for
> > > this project.
> >
> > It sounds like a plausible direction, but documentation is always
> > lacking in these kinds of things.
> >
> > As a complete outsider to targets with delay slots, merging their
> > logic sounds like a nice improvement to me (especially as Lanai is
> > probably incoming as another ISA that has decided delay slots are a
> > good idea). But (also as an outsider) I have no idea how practical
> > that really is.
> >
>
> Thanks Tim for providing more insights, I would gather more information in
> given direction. Further more here mentioned 3 tasks may be not a much work
> for some one who has a good grasp on llvm but for me it may be sufficient
> for GSoC duration. It may not be possible for Google to provide fundings
> for limited number of improvements. So I am thinking to include some TODOs
> in StackColoring.cpp and StackSlotColoring.cpp in proposal too. Will it be
> enough to demonstrate in proposal ?
>
> Still I am looking for feedback on RDF part and also if some one is willing
> to mentor me.
>
> Sincerely,
> Vivek
>
>
> > Cheers.
> >
> > Tim.
> >
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://lists.llvm.org/pipermail/llvm-dev/attachments/20160301/d19affb2/attachment-0001.html
> >
>
> ------------------------------
>
> Message: 4
> Date: Tue, 01 Mar 2016 09:30:21 -0800
> From: Mehdi Amini via llvm-dev <llvm-dev at lists.llvm.org>
> To: Hal Finkel <hfinkel at anl.gov>
> Cc: llvm-dev <llvm-dev at lists.llvm.org>
> Subject: Re: [llvm-dev] RFC: Add bitcode tests to test-suite
> Message-ID: <B2CA9359-1C2C-441D-92EF-E3ABBEF4522C at apple.com>
> Content-Type: text/plain; charset="utf-8"
>
>
> > On Mar 1, 2016, at 7:32 AM, Hal Finkel <hfinkel at anl.gov> wrote:
> >
> >
> > From: "Mehdi Amini" <mehdi.amini at apple.com>
> > To: "Hal Finkel" <hfinkel at anl.gov>
> > Cc: "llvm-dev" <llvm-dev at lists.llvm.org>, "Alina Sbirlea" <
> alina.sbirlea at gmail.com>
> > Sent: Tuesday, March 1, 2016 1:16:11 AM
> > Subject: Re: [llvm-dev] RFC: Add bitcode tests to test-suite
> >
> >
> > On Feb 29, 2016, at 10:50 PM, Hal Finkel <hfinkel at anl.gov <mailto:
> hfinkel at anl.gov>> wrote:
> >
> >
> >
> > From: "Mehdi Amini via llvm-dev" <llvm-dev at lists.llvm.org <mailto:
> llvm-dev at lists.llvm.org>>
> > To: "Alina Sbirlea" <alina.sbirlea at gmail.com <mailto:
> alina.sbirlea at gmail.com>>
> > Cc: "llvm-dev" <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org
> >>
> > Sent: Monday, February 29, 2016 7:06:51 PM
> > Subject: Re: [llvm-dev] RFC: Add bitcode tests to test-suite
> >
> >
> >
> > Sent from my iPhone
> >
> > On Feb 29, 2016, at 3:39 PM, Alina Sbirlea <alina.sbirlea at gmail.com
> <mailto:alina.sbirlea at gmail.com>> wrote:
> >
> >
> >
> > On Mon, Feb 29, 2016 at 2:06 PM, Mehdi Amini <mehdi.amini at apple.com
> <mailto:mehdi.amini at apple.com>> wrote:
> >
> > On Feb 29, 2016, at 1:50 PM, Alina Sbirlea <alina.sbirlea at gmail.com
> <mailto:alina.sbirlea at gmail.com>> wrote:
> >
> >
> >
> > On Mon, Feb 29, 2016 at 12:18 PM, Mehdi Amini <mehdi.amini at apple.com
> <mailto:mehdi.amini at apple.com>> wrote:
> >
> > On Feb 29, 2016, at 11:40 AM, Mehdi Amini via llvm-dev <
> llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote:
> >
> >
> > On Feb 29, 2016, at 11:16 AM, Alina Sbirlea via llvm-dev <
> llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote:
> >
> > All,
> >
> > To get the discussion going in a focused manner, here is an initial
> patch with a running test. The test is from the Halide suite and is
> checking the correctness of several simd operations.
> > (Notes: the patch is large due to the number of operations being tested;
> > I expect a lot of changes before actually landing it, this is simply to
> continue the discussion using a concrete example.)
> > http://reviews.llvm.org/D17726 <http://reviews.llvm.org/D17726>
> >
> > I can't figure how to download the patch *with the bitcode files* from
> Phabricator. Can you push this on github (or somewhere else)? (or if I
> missed how to proceed...).
> >
> > I was able to figure how get them "one by one", it would still be more
> convenient to have an archive or a repo to clone somewhere.
> >
> > A few questions/todos to start the discussion:
> > 1. What is a good location for these tests? They are in a separate
> Bitcode directory atm, but using the llvm_multisource. This may change to
> more closely model the approach for external tests (see next item).
> >
> > A good location would be their own external repository IMO :)
> >
> > 2. There is a single .cpp file testing all operations provided by
> individual bitcode files. I expect this to change. Instead of using
> llvm_multisource to have the same test run with specific arguments, each
> run testing a single operation.
> > 3. The building approach I took is to first link all bitcode files into
> a single one, then obtain the assembly for it, which cmake knows to take as
> an input source.
> >
> > Yeah, so I'd rather have a split-build model, with a split execution
> model. Having a gigantic bitcode file to debug an issue is not friendly.
> > I'd expect to have a .cpp file that contains the main and the logic to
> run test, and then every test that is linked-in to be executed, a bit like
> gtests is doing (there are multiple registering mechanisms that would avoid
> to declare explicitly a test in the header).
> > -> filters.h and filter_headers.h should just go away.
> >
> > I agree, this is related to point 2. The plan here is to update the
> current test .cpp file to test each operation individually. In this model
> it will be enough to link with a single bitcode file per test.
> >
> >
> > Also on the test in general: we should have an idea for each test what
> it is doing and how.
> > I was expecting your tests to be on the pattern of having an
> implementation in C++ and an implementation in Halide bitcode of a filters
> (or whatever) and run both on random data and verifies that the result is
> matching.
> > Unfortunately from what I can see you are feeding the tests with random
> data, and the tests are "blackboxes" that set an error flag if they detect
> an error.
> > This is not super robust: the compiler can mess with the error checking
> and eliminate it for instance, making any error undetected.
> >
> > The Halide bitcode filters compare the result of vectorized operations
> vs scalar runs of the same code. The error code against which we compare
> the output will be set to loose tolerance - it is currently 0. We're
> interested in codegen bugs that return the wrong value entirely, not
> accuracy differences (especially for floating point tests).
> > With the new error threshold, the data fed into may be random or read
> from provided input files, I can do either.
> > The filters will still look somewhat like blackboxes, though the name of
> the filter says what operation it's being tested and the disassembled
> bitcode files are reasonably readable.
> > Using your suggestion, the driver .cpp file will test one operation at a
> time (argvs set accordingly) and return right away once an error is found.
> Sound about right?
> >
> > All of this is great.
> > The part that is not clear to me is why isn't it to have (what does it
> buy us over, or why is it better for us compared to) a possible a C/C++
> reference implementation of the filter, and hoisting (and refactor) all the
> logic to feed the tests and validate the output *out* of the filters. A
> filter would be just the mathematical function performed and nothing more
> (separation of concerns, more robust framework, easier debugging when
> things-go-wrong, etc.).
> >
> > I believe the answer is that Halide generates vectorized code in a way
> that is not generated by llvm when starting from C/C++.
> >
> > I don't really see how *this* addresses my point. This is justifying
> why your bitcode is interesting and why we are having this conversation at
> all :)
> > It does not say why we can't have a scalar naive C/C++ impl along with
> the bitcode for filter.
> >
> >
> > Having a C/C++ scalar reference would involve quite a bit of effort for
> all tests. The primary reason Halide is being used is that you don't need
> to write a lot of C/C++ code to get different optimizations for the same
> code (e.g. vectorized vs scalar is a one line difference).
> >
> > Yes, this is what is nice with Halide: "write once, codegen multiple
> variant". But it does not mean you can't write a c++ reference for every
> Halide filter (not for every codegen variant of a filter!)
> >
> > It's been 2 years since my last experiments with Halide, but my memories
> were that there was a C backend?
> > I had in mind for each test to have (possibly in a separate directory
> for each test):
> > - the halide source for the filter.
> > - the c/c++ (maybe generated?) for the filter.
> > - the bitcode generated for the filter (potentially multiple variant
> depending on the CPU support and/or the schedule).
> >
> > Then some common code/infrastructure to interact with the individual
> filters, loading them, executing the variants for a filter, and checking
> results.
> >
> > If the reference c/c++ can't be generated by halide (or obtained
> somehow), and we can't do better than the current tests infrastructure you
> have, then I'm worried about the cost/benefit for this test-suite.
> >
> >
> > I think that a C/C++ version would be nice to have, but not necessary.
> > IR generated by non-Clang frontends and/or IR going through alternate
> optimization pipelines tend to hit bugs that are much harder to hit with
> Clang alone.
> >
> > To make it clear: the point of the C++ reference I was asking for is
> *not to stress clang* at all. It is intended to compute the *golden result*
> to be compared to the runs of each variant for a filter. Having a
> reference is important when a diff is detected in the output and you need
> to figure out what is going on.
> >
> >
> > It would help to have a description of what each test does, but
> including, for example, the Halide source code for each test will hopefully
> be enough of a guide.
> >
> > So we can get really fast test coverage for possible codegen bugs by
> comparing that different layout optimizations in Halide give the same
> result.
> > I think having each filter tested separately should give a good
> separation of concerns and easy debugging for each particular test.
> >
> > This is great for halide validation, we are all agreeing with this I
> think. The question is where is the tradeoff for the LLVM project. I'm
> trying to make sure that the extra coverage doesn't come with a burden to
> debug and triage issues when something will break: i.e. the tests need to
> be very friendly to interact with.
> >
> > I don't think that any non-trivial tests are truly "friendly" to
> interact with.
> >
> > Yeah, I just think we shouldn't make it arbitrarily worse by not having
> a good infrastructure to begin with :)
> >
> > In the end, if we expect this suite to be accepted and maintained as a
> "first-class citizen" by LLVM developers (i.e. accepting things like
> reverting a commit if it breaks something in this suite), we'd better make
> sure the burden to interact with it is minimal.
> >
> >
> > Tracking down self-hosting bugs is not friendly, and those aren't
> anywhere near the worst ;) --
> > These tests with their simple driver seem like good input that bugpoint
> can reduce (assuming the tests runtimes are not too long), and that's
> friendlier than most of the other multisource tests.
> >
> > If we're talking exclusively about crashes, I agree. However if we're
> considering correctness issue as well (miscompiles), I believe that the
> structural changes I proposed are very important to easily perform bugpoint
> on them for instance (or bugpoint would just turn the test into "return
> false;").
> > On this point, this is not exactly how bugpoint works for miscompiles.
> Instead, it tries to split the miscompiled regions into a separate module
> from the correctly-compiled regions (by moving functions, extracting loops,
> etc.), and it tries to reduce the pass list to only that causing the
> miscompile. Having the "reference" IR and the "optimized" IR in separate
> functions will certainly make this easier.
> >
> > Also I believe these changes are necessary to perform timing measurement
> for these tests, if we are interested in the quality of the
> optimization/codegen (to be hooked into something like
> https://github.com/google/benchmark <https://github.com/google/benchmark>
> ?).
> > This is a good point, although perhaps not something we need to solve
> right now.
> >
> > We already do a bad jobs here (we have benchmarks with multiple kernels,
> and we don't capture separate timings for each kernel, but only the overall
> timing for the executable). In the long run, it will be better to be able
> to get separate timing information for each of the "optimized" and
> "reference" kernels, and a direction that allows this seems better (by
> either being able to print separate timings -- not something we can do now
> -- or having separate executables). A direction that will allow this, or
> allows this in the future, is preferable. That having been said, if this is
> not practical currently, we can work towards improving this as follow-up.
>
> I agree.
> My impression was that it won't be a large scale effort to it right now,
> thanks to the way these tests are generated with Halide. Changing the
> generator (a single function I think):
> https://github.com/halide/Halide/blob/master/test/correctness/simd_op_check.cpp#L94
> <
> https://github.com/halide/Halide/blob/master/test/correctness/simd_op_check.cpp#L94>
> would make immediately the 349 bitcode files submitted fit the pattern.
>
> --
> Mehdi
>
>
>
>
>
> >
> > Thanks again,
> > Hal
> >
> > Best,
> >
> > --
> > Mehdi
> >
> >
> >
> >
> > -Hal
> >
> > This is the motivation for my comments so far.
> > Other people in the community may have a different opinion/appreciation
> of the situation, this just represents my current thoughts.
> >
> > Hope it makes sense.
> >
> > --
> > Mehdi
> >
> >
> >
> >
> >
> > Also, just looking quickly at one IR I'm surprised by things like:
> >
> > "assert succeeded165": ; preds = %"assert
> succeeded146"
> > %buf_host181 = getelementptr inbounds %struct.buffer_t,
> %struct.buffer_t* %error_op_pcmpeqq_272.buffer, i64 0, i32 1
> > %23 = bitcast i8** %buf_host181 to double**
> > %error_op_pcmpeqq_272.host226227232 = load double*, double** %23,
> align 8
> > %24 = icmp eq %struct.buffer_t* %error_op_pcmpeqq_272.buffer, null
> > br i1 %24, label %"assert failed183", label %"assert succeeded184",
> !prof !4
> >
> > Here you have as check for nullptr at %24, but you already loaded
> %error_op_pcmpeqq_272.host226227232 from this pointer just before!
> >
> > It's checking that the host value loaded from buffer_t is not null. I
> don't see what's wrong with this. What am I missing?
> >
> > I may be misreading it, my impression when skimming through the code was
> that it seems equivalent to:
> >
> > foo(buffer_t *out) {
> > auto value = out->host;
> > if (!out) {
> > error("nullptr");
> > }
> > }
> >
> >
> > In case I haven't been clear: I think this work is valuable for the
> project, and thank you for putting some effort into it :)
> >
> > --
> > Mehdi
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > A separate discussion is on reading metadata (mcpu and mattr) in llc. I
> added a script to work around that for now.
> >
> > The generic way of doing it in llvm is (I think) to use function
> attributes:
> >
> > attributes #0 = { "target-cpu"="x86-64" "target-features"="+avx2" }
> >
> > You shouldn't need it on the command line I think?
> >
> > Yes, I believe so too. Currently these are set in mcpu and mattr by
> Halide and not read in by llc, hence the need for feeding them as
> parameters. It's a separate issue that we'll need to go into in depth, but
> I don't want it to interfere with getting feedback on how to best publish
> these tests.
> >
> >
> > --
> > Mehdi
> >
> >
> >
> >
> > Looking forward to your feedback!
> >
> > Thanks,
> > Alina
> >
> >
> >
> > On Fri, Feb 19, 2016 at 6:50 AM, Kristof Beyls <kristof.beyls at arm.com
> <mailto:kristof.beyls at arm.com>> wrote:
> >
> >
> > On 18/02/2016 19:12, Alina Sbirlea via llvm-dev wrote:
> >
> >
> > I have more questions for Alina. What kind of tests do you have:
> >
> > - "the compiler takes the bitcode and generates code without crashing"
> > - "the compiled test runs without crashing"
> > - "the compiled test will produce an output that be checked against a
> reference"
> > - "the compiled test is meaningful as a benchmarks"
> >
> > We have all 4 kinds of tests in Halide. The bitcode files for the first
> category is already available and I'm working on building the ones for the
> next 3. We'd like to include all incrementally.
> >
> >
> > It seems to me that the first category ("the compiler takes the bitcode
> and generates code without crashing") are tests that should be added to the
> "make check-all" tests in the LLVM subproject, rather than the test-suite
> subproject?
> > Or if these tests currently don't crash the compiler anymore, the bugs
> must have been fixed, and there should already be equivalent tests?
> >
> > _______________________________________________
> > LLVM Developers mailing list
> > llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>
> > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev <
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev>
> >
> > _______________________________________________
> > LLVM Developers mailing list
> > llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>
> > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev <
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev>
> >
> >
> >
> >
> > _______________________________________________
> > LLVM Developers mailing list
> > llvm-dev at lists.llvm.org <mailto: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/20160301/f8373682/attachment-0001.html
> >
>
> ------------------------------
>
> Message: 5
> Date: Tue, 1 Mar 2016 09:39:21 -0800
> From: Alexey Samsonov via llvm-dev <llvm-dev at lists.llvm.org>
> To: Peter Teoh <htmldeveloper at gmail.com>
> Cc: llvm-dev <llvm-dev at lists.llvm.org>
> Subject: Re: [llvm-dev] Compiler-RT cmake building
> Message-ID:
> <CAFBZoY_9s4=
> fjv46aTxv+cEWG8Muwowo+-WKt7nrswFmUqcmcQ at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> Hi Peter,
>
> On Tue, Mar 1, 2016 at 4:32 AM, Peter Teoh via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
>
> > After issuing:
> >
> > cmake -DLLVM_ENABLE_DOXYGEN=ON -DLLVM_ENABLE_WERROR=OFF
> > -DLLVM_TARGETS_TO_BUILD="X86" ../llvm
> >
> > I got the following results.
> >
> > Not sure what does the "failed" means?
> >
>
> That's fine - it just means that your compiler doesn't support certain
> flags (most of them are MSVC-specific, so this is
> totally expected). You should still be able to build successfully.
>
>
> >
> > -- Performing Test COMPILER_RT_HAS_W3_FLAG
> > -- Performing Test COMPILER_RT_HAS_W3_FLAG - Failed
> > -- Performing Test COMPILER_RT_HAS_WX_FLAG
> > -- Performing Test COMPILER_RT_HAS_WX_FLAG - Failed
> > -- Performing Test COMPILER_RT_HAS_WD4146_FLAG
> > -- Performing Test COMPILER_RT_HAS_WD4146_FLAG - Failed
> > -- Performing Test COMPILER_RT_HAS_WD4291_FLAG
> > -- Performing Test COMPILER_RT_HAS_WD4291_FLAG - Failed
> > -- Performing Test COMPILER_RT_HAS_WD4391_FLAG
> > -- Performing Test COMPILER_RT_HAS_WD4391_FLAG - Failed
> > -- Performing Test COMPILER_RT_HAS_WD4722_FLAG
> > -- Performing Test COMPILER_RT_HAS_WD4722_FLAG - Failed
> > -- Performing Test COMPILER_RT_HAS_WD4800_FLAG
> > -- Performing Test COMPILER_RT_HAS_WD4800_FLAG - Failed
> > -- Looking for __func__
> > -- Looking for __func__ - found
> > -- Looking for fopen in c
> > -- Looking for fopen in c - found
> > -- Looking for dlopen in dl
> > -- Looking for dlopen in dl - found
> > -- Looking for shm_open in rt
> > -- Looking for shm_open in rt - found
> > -- Looking for pow in m
> > -- Looking for pow in m - found
> > -- Looking for pthread_create in pthread
> > -- Looking for pthread_create in pthread - found
> > -- Looking for __cxa_throw in stdc++
> > -- Looking for __cxa_throw in stdc++ - found
> > -- Looking for __i686__
> > -- Looking for __i686__ - not found
> > -- Looking for __i386__
> > -- Looking for __i386__ - not found
> > -- Compiler-RT supported architectures: x86_64
> > -- Looking for rpc/xdr.h
> > -- Looking for rpc/xdr.h - found
> > -- Looking for tirpc/rpc/xdr.h
> > -- Looking for tirpc/rpc/xdr.h - found
> > -- Performing Test COMPILER_RT_TARGET_HAS_ATOMICS
> > -- Performing Test COMPILER_RT_TARGET_HAS_ATOMICS - Success
> > -- Clang version: 3.9.0
> > -- Performing Test CXX_SUPPORTS_NO_NESTED_ANON_TYPES_FLAG
> > -- Performing Test CXX_SUPPORTS_NO_NESTED_ANON_TYPES_FLAG - Failed
> > -- Configuring done
> > -- Generating done
> > -- Build files have been written to: /home/tthtlc/llvm/build1mar2016
> >
> >
> > --
> > Regards,
> > Peter Teoh
> >
> > _______________________________________________
> > LLVM Developers mailing list
> > llvm-dev at lists.llvm.org
> > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
> >
> >
> --
> Alexey Samsonov
> vonosmas at gmail.com
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://lists.llvm.org/pipermail/llvm-dev/attachments/20160301/63927b2e/attachment-0001.html
> >
>
> ------------------------------
>
> Message: 6
> Date: Tue, 1 Mar 2016 18:49:51 +0100
> From: Kai Nacke via llvm-dev <llvm-dev at lists.llvm.org>
> To: Justin Bogner <mail at justinbogner.com>, Kai Nacke via llvm-dev
> <llvm-dev at lists.llvm.org>
> Subject: Re: [llvm-dev] Compiling for AArch64: CommandLine Error:
> Option 'aarch64-branch-relax' registered more than once!
> Message-ID: <69a86847-9d2e-8dec-2b12-b118e4170471 at redstar.de>
> Content-Type: text/plain; charset=windows-1252; format=flowed
>
> On 27.02.2016 22:45, Justin Bogner wrote:
> > Kai Nacke via llvm-dev <llvm-dev at lists.llvm.org> writes:
> >> Compiling for AArch64: CommandLine Error: Option
> >> 'aarch64-branch-relax' registered more than once!
> >>
> >> Hi all!
> >>
> >> I am trying to run LDC (LLVM-based D compiler) on AArch64. The
> >> compiler contains all IR and target specific passes. You can view it
> >> as combined llc/opt tool. It uses the same strategy as opt to collect
> >> the passes with the NameParser. Like llc, it calls
> >> Target.addPassesToEmitFile() to add the target specific passes.
> >>
> >> I now get the following error message:
> >>
> >> ldc2.exe: CommandLine Error: Option 'aarch64-branch-relax' registered
> >> more than once!
> >> LLVM ERROR: inconsistency in registered CommandLine options
> >>
> >> Reason is that the option 'aarch64-branch-relax' is registered in file
> >> lib/Target/AArch64/AArch64BranchRelaxation.cpp and a second time
> >> through PassRegistry::registerPass() (because of the use of the
> >> NameParser - the pass is also named 'aarch64-branch-relax').
> >
> > I wouldn't really recommend using the NameParser outside of a testing
> > tool. The "throw all of the pass names at cl::opt and see what sticks"
> > thing is pretty specialized to opt and makes for a pretty messy command
> > line interface for something that does anything other than just running
> > passes.
> >
> > That said, the aarch64-branch-relax option in AArch64BranchRelaxation is
> > a bit silly: it's only useful for *disabling* the pass, despite the
> > name, and it isn't tested at all. I suspect it's just leftover from when
> > this pass was first being implemented and can be removed.
> >
> > Tim: does it make sense to just remove this flag?
>
> Hi Justin!
>
> Thanks for the answer! I think I will remove this "feature" from ldc.
> Looks like asking for more trouble if I keep it...
>
> Regards,
> Kai
>
>
> ------------------------------
>
> Subject: Digest Footer
>
> _______________________________________________
> llvm-dev mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
>
> ------------------------------
>
> End of llvm-dev Digest, Vol 141, Issue 4
> ****************************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160301/ece7ced7/attachment-0001.html>
More information about the llvm-dev
mailing list