PSA: chrome/android is now built with clang

[Nico Weber]

Hi,

as of last Friday, the default compiler on android is now clang (https://crbug.com/481675). The change is still in, and by now it looks like it will stick.

I believe Android was the last platform using gcc. Now that the Android bots no longer use gcc, I believe we have no CQ bots that use gcc. We still support patches for gcc compat from the community, but it's possible building with gcc will now require more community maintenance than before.

If you don't work on Android, this shouldn't affect you and you can stop reading now.

If you do work on Android, it shouldn't affect you much either. One thing that I've seen is that clang produces code that makes more alignment assumptions: ARM processors raise SIGBUS if you e.g. try to read a 4-byte int off an unaligned address, and clang seems to emit these aligned read isntructions more frequently. For example, if you have this function:

uint32_t GetHeaderValue(void* data, int offset) const {

  uint32_t value = *reinterpret_cast<uint32_t*>(data + offset)

  return value;

}

then this will in general read 4 bytes off an unaligned address (unless data + offset happens to be divisible by 4). The fix is to do bytewise loads (or use base's bit_cast):

uint32_t GetHeaderValue(int offset) const {

  uint32_t value;

  memcpy(&value, data_ + offset, sizeof(value));

  return value;

}

All three bugs I've seen during turning on clang were due to this. This is a problem only rarely, but if it happens it's hard to understand if you haven't seen it before, hence this lengthy treatise. (More examples in the CLs of https://crbug.com/729059 https://crbug.com/726137 https://crbug.com/732061).

Nico

ps: Binary size went down 300kB and performance looks generally pretty positive: https://chromeperf.appspot.com/group_report?rev=478517

[Dirk Pranke]

This is fantastic, thanks to everyone involved for working on this!

-- Dirk

--
--
Chromium Developers mailing list: chromi...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-dev
---
You received this message because you are subscribed to the Google Groups "Chromium-dev" group.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-dev/CAMGbLiGKYsGr-XajXLS88gG4Nu8SFBg3paYhTuZgGaPeV%2B9dKw%40mail.gmail.com.

[Jeremy Roman]

Hooray! \o/

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-dev/CAEoffTBwEowLfuDw0nxwttRMWABA1xmfqfUb2CWC8Y2Up%3DF%3DcQ%40mail.gmail.com.

[James Cook]

+vapier, are we still doing gcc builds of chrome for old 32-bit Intel Chromebooks? Or has that stopped now that M58 is out the door?

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-dev/CACuR13dcmNNHLufujia8OZ7aLjo7a14PGB3ui6kqUSiOQ63%2BAg%40mail.gmail.com.

[Mike Frysinger]

wrt Chrome, we're in the process of turning down 32-bit builders.  but they aren't turned off yet -- you can see x86-generic on the public waterfall and the chromium pfq for example.

wrt clang-vs-gcc, we're still using gcc on them.

Luis might know the current progress of the turn down.

-mike

[Andrew Grieve]

If anyone is curious about how 300kb was saved by clang, I've done some binary size analysis on the switch here:

https://bugs.chromium.org/p/chromium/issues/detail?id=656048

Hard to find anything super-actionable out of it, but it at least does show that there is more binary-size savings that could be had with more investment in clang (since some areas clearly got bigger, even though overall size decreased).

--

[Mike Frysinger]

> (And why is this being asked in chromium-dev ? )

if you scroll back to the first post from Nico, he discusses gcc support explicitly

-mike

On Fri, Jun 16, 2017 at 1:31 PM, Luis Lozano <llo...@google.com> wrote:

+akeshet 

we never transitioned to clang for the 32-bit builders because we knew they were going to die.

I am surprised we are still building x86-32 generic. Dont know the reason for that.

We eliminated all the toolchain-specific builders for x86-32 and I am eliminating last trace of any GCC testing for x86-32 generic today. 

Any reason to ask about GCC?

(And why is this being asked in chromium-dev ? )