Known issue? qemu is much slower when built with clang vs gcc

Known issue? qemu is much slower when built with clang vs gcc

[Taylor Simpson]

[-- Attachment #1: Type: text/plain, Size: 908 bytes --]

We're seeing significant slowdowns when we build qemu with clang instead of gcc.  I'm hoping this is a known issue and there is a workaround or fix.  Please advise.

I have an example where qemu is 29X slower when built with clang.  My first hunch was that there was something different happening in configure (e.g., passing -O0 to clang instead of -O2).  However, I have ruled this out.

Further investigation shows that we are calling the translator more often.  The same code is getting translated multiple times.  So, my current theory is some different behavior in the translation block hashing causing the lookup not to find existing translations.  I know clang can be overly aggressive about optimizing undefined behavior.  So, I turned on clang's undefined behavior sanitizer.  Interestingly, it did not report anything, *and* we don't see the large performance difference.

Thanks,
Taylor


[-- Attachment #2: Type: text/html, Size: 2737 bytes --]

RE: Known issue? qemu is much slower when built with clang vs gcc

[Brian Cain]

[-- Attachment #1: Type: text/plain, Size: 1342 bytes --]

Taylor,

I can report that the performance looks to be in the ballpark of parity with gcc when we move from clang 8.0 to 11.0 rc2.   Perhaps we can attribute this to a since-fixed defect in clang?

-Brian

From: Taylor Simpson <tsimpson@quicinc.com>
Sent: Monday, August 24, 2020 11:54 AM
To: qemu-devel@nongnu.org
Cc: Brian Cain <bcain@quicinc.com>
Subject: Known issue? qemu is much slower when built with clang vs gcc

We're seeing significant slowdowns when we build qemu with clang instead of gcc.  I'm hoping this is a known issue and there is a workaround or fix.  Please advise.

I have an example where qemu is 29X slower when built with clang.  My first hunch was that there was something different happening in configure (e.g., passing -O0 to clang instead of -O2).  However, I have ruled this out.

Further investigation shows that we are calling the translator more often.  The same code is getting translated multiple times.  So, my current theory is some different behavior in the translation block hashing causing the lookup not to find existing translations.  I know clang can be overly aggressive about optimizing undefined behavior.  So, I turned on clang's undefined behavior sanitizer.  Interestingly, it did not report anything, *and* we don't see the large performance difference.

Thanks,
Taylor


[-- Attachment #2: Type: text/html, Size: 3711 bytes --]

RE: Known issue? qemu is much slower when built with clang vs gcc

[Taylor Simpson]

[-- Attachment #1: Type: text/plain, Size: 1671 bytes --]

OK, thanks Brian!


From: Brian Cain <bcain@quicinc.com>
Sent: Monday, August 24, 2020 9:50 PM
To: Taylor Simpson <tsimpson@quicinc.com>; qemu-devel@nongnu.org
Subject: RE: Known issue? qemu is much slower when built with clang vs gcc

Taylor,

I can report that the performance looks to be in the ballpark of parity with gcc when we move from clang 8.0 to 11.0 rc2.   Perhaps we can attribute this to a since-fixed defect in clang?

-Brian

From: Taylor Simpson <tsimpson@quicinc.com<mailto:tsimpson@quicinc.com>>
Sent: Monday, August 24, 2020 11:54 AM
To: qemu-devel@nongnu.org<mailto:qemu-devel@nongnu.org>
Cc: Brian Cain <bcain@quicinc.com<mailto:bcain@quicinc.com>>
Subject: Known issue? qemu is much slower when built with clang vs gcc

We're seeing significant slowdowns when we build qemu with clang instead of gcc.  I'm hoping this is a known issue and there is a workaround or fix.  Please advise.

I have an example where qemu is 29X slower when built with clang.  My first hunch was that there was something different happening in configure (e.g., passing -O0 to clang instead of -O2).  However, I have ruled this out.

Further investigation shows that we are calling the translator more often.  The same code is getting translated multiple times.  So, my current theory is some different behavior in the translation block hashing causing the lookup not to find existing translations.  I know clang can be overly aggressive about optimizing undefined behavior.  So, I turned on clang's undefined behavior sanitizer.  Interestingly, it did not report anything, *and* we don't see the large performance difference.

Thanks,
Taylor


[-- Attachment #2: Type: text/html, Size: 4653 bytes --]