LLVM Bugzilla is read-only and represents the historical archive of all LLVM issues filled before November 26, 2021. Use github to submit LLVM bugs

Bug 20422 - [Meta] Chromium building with -integrated-as on ARM
Summary: [Meta] Chromium building with -integrated-as on ARM
Status: NEW
Alias: None
Product: libraries
Classification: Unclassified
Component: Backend: ARM (show other bugs)
Version: trunk
Hardware: PC All
: P normal
Assignee: Unassigned LLVM Bugs
URL:
Keywords:
Depends on: 20423 20426 20427 20428 20429 20447 20700 20702 23000 25720 25722 31058
Blocks: 21420
  Show dependency tree
 
Reported: 2014-07-23 19:14 PDT by Nico Weber
Modified: 2016-11-21 16:03 PST (History)
7 users (show)

See Also:
Fixed By Commit(s):


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Nico Weber 2014-07-23 19:14:34 PDT
Chromium currently uses -fno-integrated-as since using the integrated as leads to compile errors. I'll file one bug per issue and mark this bug here blocked on all issues.
Comment 1 Nico Weber 2014-07-23 19:54:31 PDT
(upstream bug is https://code.google.com/p/chromium/issues/detail?id=124610)

Renato, maybe you know if anyone cares about this?
Comment 2 Renato Golin 2014-07-24 08:05:51 PDT
Hi Nico,

I'm interested in IAS bugs, as well as some other folks like Saleem and ARM, but I can't pursue the Chromium project myself. I hadn't seen the attached bugs to this one, but I will now.

As a general rule, pre-UAL support as well as GNU extensions have less priority and might not even be implemented, with the rule of thumb being about the complexity of the patch needed to enable support. If it's just an alias or a simple match, it should be ok, but if it needs substantial support from the assembler *just* for that legacy/extension, than it's likely not going in.

I'll review each one of the depending bugs individually, thanks for getting my attention to this.

cheers,
--renato
Comment 3 Nico Weber 2014-07-24 09:56:55 PDT
> I hadn't seen the attached bugs to this one, but I will now.

Cool. It's probably not a complete list; I'll add more things over time.

> pre-UAL support

What's "UAL"?

> as well as GNU extensions

Is there a standard for assemblers? I thought it's all implementation-defined. How do I know if something is a GNU extension? (The two patches I've sent so far fall into the "low complexity" bucket though, I think.)
Comment 4 Saleem Abdulrasool 2014-08-03 10:42:09 PDT
(In reply to comment #3)
> 
> > pre-UAL support
> 
> What's "UAL"?

Unified assembly language.  The ARM assembly evolved over time, and had lots of different mnemonics that behaved slightly differently.  In order to simplify things, the FPU and CPU operations were renamed and made uniform and became known as UAL.

GAS doesn't default to it, though it supports it.  Just make sure that you add

  .syntax unified

to the beginning of any assembly file and things should be completely compatible against any reasonably recent version of binutils and LLVM IAS.
Comment 5 Renato Golin 2014-08-03 11:51:20 PDT
Hi Saleem,

Thanks for answering the question, I completely missed that.

Nico, about the standards for ASM, unfortunately there isn't. UAL is an attempt from ARM to create a unified assembly syntax, but there are probably as many extensions from GNU, ARM and LLVM together than there are rules. The UAL not only unified ARM and Thumb, but also deprecated some old mnemonics.

http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0473c/BABJIHGJ.html

Most of the problems we have now on the integrated ARM assembler are due to pre-UAL and extensions syntax being used in the wild, and we have to balance implementing them or kindly requesting the users to update their syntax. The rules of thumb are:

* Non-extensions/non-pre-UAL issues are critical, needs fixing in the integrated assembler.

* Extensions/pre-UAL can be fixed in the assembler if:
 - The syntax is an alias/mnemonic to a UAL token and implementing it would just mean adding a new case to a switch or similar.
 - The syntax is widely used in the wild and asking all users would be impractical. In this case, a discussion should be held as to what's the best way to implement without making the whole code worse. We might decide we can't.

* Changes that require deep changes to the compiler, or are easily worked around by another feature, or would make it harder to maintain other areas of the compiler should NOT go in.
Comment 6 Nico Weber 2016-03-17 12:54:46 PDT
Current status: -integrated-as is enabled for all but four targets (https://bugs.chromium.org/p/chromium/issues/detail?id=124610#c33)