[llvm-dev] RFC: Building GlobalISel by default

[Michael Kuperstein via llvm-dev]

On 14 January 2017 at 10:53, Mehdi Amini via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

>
> > On Jan 14, 2017, at 4:57 AM, Renato Golin via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
> >
> > On 14 January 2017 at 01:54, Quentin Colombet via llvm-dev
> > <llvm-dev at lists.llvm.org> wrote:
> >> Now, four backends (if I am counting right: X86, ARM, AArch64, AMDGPU)
> are working on bringing-up GlobalISel, I’d like to switch the default of
> the LLVM_BUILD_GLOBAL_ISEL variable in CMake, such that the framework gets
> built by default.
> >
> > Hi Quentin,
> >
> > I'm not extremely confident in a full switch right now, mainly due to
> > Michael's concerns. The ARM port is in its initial stage and there
> > could still be many refactorings and destructive changes. I'm not
> > foreseeing a cross between the isel tests, but every failure makes the
> > bots red, and if Global ISel incurs in more failures due to its stage
> > in the development cycle, we'll start seeing the bots more red than
> > we'd like. Right now, it's already very likely that you'll receive bot
> > emails on commits, I don't want to increase that.
>
> I don’t see why having global ISel is supposed to increase the rate. `make
> check` will runs on the committer machine with GlobalISel enabled.
>
> The good question from Michael is IMO "if my (non-GlobalISel) change
> breaks GlobalISel, how likely is it to be a bug in my code vs. a bug in
> GlobalISel?”
>
> But that’s totally unrelated to the bots, since it’ll fails on the
> committer machine as well.
>
>
To emphasize this - I don't think the bots should be a blocker, the issue
that bothers me is local developer workflow.

Regarding "we shouldn't enable it because it will make the bots slower" -
well, yes, but that's just postponing the inevitable. We will enable
GlobalISel eventually, and there will probably be a very long time-frame
during which both are enabled concurrently. If we expect to have some magic
solution to make overall testing much faster in the near future, it may
make sense to delay until it's implemented. But I'm not aware of anything
like that.

As to it making the bots "redder" because of failures in the newer
GlobalISel ports - if devs don't see a lot of local breakage, then the
effect on the bots shouldn't be big either. And if they do, I think it's a
non-starter anyway.
Still, as a strawman proposal - would it make sense to add
LLVM_BUILD_GLOBAL_ISEL_EXPERIMENTAL,
or something of that sort? The more mature ports will build under
LLVM_BUILD_GLOBAL_ISEL (which will be enabled by default), the less mature
ones only under LLVM_BUILD_GLOBAL_ISEL_EXPERIMENTAL (which won't be), and
moving a port from GLOBAL_ISEL_EXPERIMENTAL to GLOBAL_ISEL would be
equivalent to marking a regular backend non-experimental. We can start with
just AArch64 in the non-experimental category, and move the others as they
become more stable.
Or is this too much complexity for what we gain?

Michael
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170114/da8f2558/attachment.html>