This is an archive of the discontinued LLVM Phabricator instance.

LLVM gen correct asm info for mingw and cygwin arm targets
ClosedPublic

Authored by martell on Jul 9 2015, 11:24 AM.

Details

Reviewers
yaron.keren
rnk
Summary

Relative clang review

http://reviews.llvm.org/D11071

Diff Detail

Event Timeline

martell updated this revision to Diff 29365.Jul 9 2015, 11:24 AM
martell retitled this revision from to LLVM gen correct asm info for mingw and cygwin arm targets.
martell updated this object.
yaron.keren edited edge metadata.Jul 9 2015, 11:30 AM

Hi, could you update both patches with more context as detailed in

http://llvm.org/docs/Phabricator.html

it really makes reviewing and discussing much easier with the context around the patches.

martell updated this revision to Diff 29386.Jul 9 2015, 1:56 PM

Hi, could you update both patches with more context as detailed in

http://llvm.org/docs/Phabricator.html

it really makes reviewing and discussing much easier with the context around the patches.

done :)

It should be possible to write tests for this; we try to make sure all patches with functional changes have something committed under tests/ too, to prevent mistakes on later refactoring if nothing else.

Tim.

It should be possible to write tests for this; we try to make sure all patches with functional changes have something committed under tests/ too, to prevent mistakes on later refactoring if nothing else.

Tim.

The relative tests for this code path have already been introduced in this revision
http://reviews.llvm.org/D3231

I could recreate all the tests with the windows-gnu triplet but they would all fail until
http://reviews.llvm.org/D11071
is approved and merged

Should we wait for that ?

I could recreate all the tests with the windows-gnu triplet but they would all fail until http://reviews.llvm.org/D11071 is approved and merged

Speaking of which, that could do with some tests too.

But I'm not sure how a Clang patch can have any influence on LLVM tests. This appears to be changing something about how llc would emit object files (and assembly? I don't know) when using these triples. That's what should be tested with this patch.

I could recreate all the tests with the windows-gnu triplet

If the same behaviour is expected, you should be able to just add a second "RUN" line to those tests.

Cheers.

Tim.

martell updated this revision to Diff 29428.Jul 9 2015, 10:18 PM

Added relevant test cases as requested by Tim :)

I'm afraid I don't think these are the right tests to be adding.

They all seem to pass already, so they're unrelated to the change you're making. The only difference I've seen during some brief fiddling is when -filetype=obj is used (your change prevents some assertion failure), though looking at the source it probably affects some other details too.

rnk accepted this revision.Jul 10 2015, 9:58 AM
rnk edited edge metadata.

lgtm with those tests

lib/Target/ARM/MCTargetDesc/ARMMCTargetDesc.cpp
281–285

It's probably cleaner to flip the order to this:

else if (TheTriple.isWindowsMSVCEnvironment())
  MAI = new ARMCOFFMCAsmInfoMicrosoft();
else if (TheTriple.isOSWindows())
  MAI = new ARMCOFFMCAsmInfoGNU();
else ...

We basically have the MS environment and then the GNU-ish "everything else" one.

test/CodeGen/ARM/Windows/no-arm-mode.ll
9

OK, so mingw will presumably also be focusing on a thumb-only, winrt, environment?

test/CodeGen/ARM/Windows/pic.ll
6

Can you add a comment about the purpose of this test? Is the code sequence below actually a PIC sequence?

This revision is now accepted and ready to land.Jul 10 2015, 9:58 AM

I'm afraid I don't think these are the right tests to be adding.

They all seem to pass already, so they're unrelated to the change you're making. The only difference I've seen during some brief fiddling is when -filetype=obj is used (your change prevents some assertion failure), though looking at the source it probably affects some other details too.

Yes you are correct it does prevent an assertion failure.
Itanium seems to use these tests for that purpose also so I don't think I should make a specific assertion test for gnu when there isn't one for itanium or msvc.
The test structors.ll has a different section name with gnu so this test would most definitely fail if the target wasn't supported.

The only other test I can think of todo is alloca.ll where we use chkstk_ms instead of chkstk but I will put that in a separate commit as i have to edit the code gen for that.

In D11075#202858, @rnk wrote:

OK, so mingw will presumably also be focusing on a thumb-only, winrt, environment?

Yes the target will windows NT just like msvc and itanium :)
Windows store / Desktop

Can you add a comment about the purpose of this test? Is the code sequence below actually a PIC sequence?

I could be wrong but to me the purpose of this test is to ensure to load of an external global is done via the movw movt pair
A branch is done the same way and this test seems to ensure the relocation model doesn't affect this.
I was actually not expecting gnu to do this the correct way.

It's probably cleaner to flip the order to this:
else if (TheTriple.isWindowsMSVCEnvironment())

MAI = new ARMCOFFMCAsmInfoMicrosoft();

else if (TheTriple.isOSWindows())

MAI = new ARMCOFFMCAsmInfoGNU();

else ...
We basically have the MS environment and then the GNU-ish "everything else" one.

I will update the patch to reflect this :)

martell updated this revision to Diff 29456.Jul 10 2015, 11:08 AM
martell edited edge metadata.

updated to a less expensive check as suggested by rnk

ping! can someone commit this please :)

martell added a subscriber: yaron.keren.
yaron.keren accepted this revision.Jul 13 2015, 11:13 PM
yaron.keren added a reviewer: yaron.keren.

r242123

yaron.keren closed this revision.Jul 13 2015, 11:13 PM