LLC ARM Backend maintainer

Hi all,

I’m new to this list and I would like to know who is involved in llc ARM backend maintenance/evolution.

– Seb

If you would like to discuss something in particular about the ARM
backend, please direct any questions here; all the relevant people are
subscribed to this list.

-Eli

Hi,

Anton Korobenikov is the designated "maintainer", but ARM is one of the most active targets so plenty of people commit to it. We at ARM also commit to the back end.

In general any questions you would ask a maintainer you should just post to the list and people will reply.

Cheers,

James

Hi James,

Anton Korobenikov is the designated "maintainer",

I really-really don't know who said this at first. I'm definitely
*not* a maintainer.

Hi Anton,

I do apologise - I was under the impression that you were. Re-reading http://llvm.org/docs/DeveloperPolicy.html#owners, I see you're actually down for EH, debug info and Windows.

Sorry about that!

J

Hi all,

To answer Eli question, I wanted to know who is actively working on ARM because I submitted some bug report (#11029, #9905) and don’t know if someone is working on them, if/when the will be fixed. Maybe I just need to better understand LLVM release process, I’ve seen a mail in this list about it.

– Seb

Hi all,

To answer Eli question, I wanted to know who is actively working on ARM because I submitted some bug report (#11029, #9905) and don't know if someone is working on them, if/when the will be fixed. Maybe I just need to better understand LLVM release process, I've seen a mail in this list about it.

Bugs get fixed if there are people to fix them. There are numerous people working on ARM and patches are also accepted.

ARM is not currently a target that we support for releases. So those bugs are not release blockers.

-Tanya

Hi Tanya,

The new type-legalization mode (-promote-elements) which enables vector-select in LLVM (and a nice perf boost for several workloads), is currently disabled because of a _single_ bug in the ARM codegen which makes a few tests fail. If ARM is not a supported target, can I mark these tests as 'XFAIL' and enable vector-select support in LLVM ?

Thanks,
Nadav

Hi Nadav,

The new type-legalization mode (-promote-elements) which enables vector-select in LLVM (and a nice perf boost for several workloads), is currently disabled because of a _single_ bug in the ARM codegen which makes a few tests fail. If ARM is not a supported target, can I mark these tests as 'XFAIL' and enable vector-select support in LLVM ?

Which testcase is it?

Anton,

"CodeGen/ARM/vrev.ll" is one of the failing tests. You can make it fail if you run it with '-promote-elements'.

Here is a short description from PR10902:

"""
The failure in CodeGen/ARM/vrev.ll is due to the lack of support for
legalizing trunc-store/load on ARM. The code we have in LegalizeDAG assumes that the
scalars making the saved vector are legal. So, the vector <2 x i16> is
scalarized to two i16, which are illegal on ARM.
"""

Thanks,
Nadav

No. Note the qualifying phrase "for releases" on Tanya's statement. If, during release testing, a regression is found on ARM compared to 2.9 results, it is not required by process to be considered a release blocker. That does not mean features can or should be enabled which knowingly break ARM. That's an entirely different situation.

-Jim

Exactly as Jim said :slight_smile:

I'm only talking about releases and release blockers. Its also a bit of a grey area when you are talking about just ARM codgen tests in the regression test suite because those should always be passing regardless of what target/os you are testing on (assuming you built the arm backend which the release team typically does). As it stands now we don't have ARM as a supported target just because there is no qualification plan for it (ie. no one running the test suite or some other benchmarks on an ARM device for example) and no real support to qualify it. If someone wants to initiate this process, it can be talked about post-3.0.

-Tanya