Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

GCC compiler option should include '-mcpu=hs38' for HSDK #31757

Closed
jacoba-at opened this issue Jan 28, 2021 · 10 comments
Closed

GCC compiler option should include '-mcpu=hs38' for HSDK #31757

jacoba-at opened this issue Jan 28, 2021 · 10 comments
Assignees
Labels
area: ARC ARC Architecture bug The issue is a bug, or the PR is fixing a bug priority: low Low impact/importance bug
Milestone

Comments

@jacoba-at
Copy link

Describe the bug
When building Zephyr for the HSDK board, it passed to gcc the option '-mcpu=hs'. This creates code that misses some processor functionality. For example if you use modulo C operator (a % b), it calls a function to perform this operation, instead of using the 'REM' assembly instruction.

To Reproduce
Steps to reproduce the behavior:

  1. west -v build -b hsdk ....
  2. Observe the compiler flags passed to gcc.

Expected behavior
I would expect to see '-mcpu=hs38' and not 'mcpu=hs'

Impact
I ran a test that uses heavily the modulo operator and it ran x4 slower without the -mcpu=hs38 flag.

Environment (please complete the following information):

  • OS: Linux
  • Toolchain : Zephyr sdk-0.11.4
  • Commit Zypher 2.4.0

Additional context
How can I add more flags or override some to the zephyr compilation? I tries adding zephyr_cc_option() to my application CMakeLists.txt , but didn't effected to compilation flags.

@jacoba-at jacoba-at added the bug The issue is a bug, or the PR is fixing a bug label Jan 28, 2021
@nashif nashif added the area: ARC ARC Architecture label Jan 29, 2021
@nashif
Copy link
Member

nashif commented Jan 29, 2021

@abrodkin FYI

@nashif nashif added the priority: low Low impact/importance bug label Jan 30, 2021
@nashif
Copy link
Member

nashif commented Feb 9, 2021

@abrodkin @evgeniy-paltsev ping

@abrodkin
Copy link
Collaborator

abrodkin commented Feb 9, 2021

We do plan to address that, but the idea was to do it for the v2.6 to not add more troubles in yet stabilized v2.5.
Or @nashif you prefer us to do that last second fix?
@jacoba-at how critical is this one for you? Please note that in case of MW tools we use right set of options (https://github.com/zephyrproject-rtos/zephyr/blob/master/soc/arc/snps_arc_hsdk/CMakeLists.txt#L14) which matches HSDK's SoC .tcf.

@nashif nashif added this to the v2.6.0 milestone Feb 9, 2021
@jacoba-at
Copy link
Author

I do have a WA for this by patching the GCC cmake file, so no critical. As for the support of HSDK with MW toolchain (#30162) that you mentioned, would this be available for 2.5., or only in 2.6?

@abrodkin
Copy link
Collaborator

@jacoba-at since we're talking about an issue in libs bundled with MW toolchain it doesn't have any direct connection with a Zephyr release, instead it has to do with MW toolchain release.

That said if this atomics problem gets fixed in the next release 2021.03 of MW tools, then you'll be able to use that newer MW version with Zephyr 2.5 as well as with 2.6 etc.

In the meantime I'd strongly suggest you to file a formal customer case via Synopsys Solvnet (https://solvnet.synopsys.com) to add more visibility to our engineering team referring to #30162.

@github-actions
Copy link

This issue has been marked as stale because it has been open (more than) 60 days with no activity. Remove the stale label or add a comment saying that you would like to have the label removed otherwise this issue will automatically be closed in 14 days. Note, that you can always re-open a closed issue at any time.

@github-actions github-actions bot added the Stale label Apr 12, 2021
@jacoba-at
Copy link
Author

Please remove the stale label.

@abrodkin abrodkin removed the Stale label Apr 12, 2021
@abrodkin
Copy link
Collaborator

@jacoba-at just FYI we do remember about adding -mcpu [and probably more compiler options] to match real SoC configuration. But now we're about to submit support of ARCv3 64-bit processors (see https://www.synopsys.com/dw/ipdir.php?ds=arc-HS6x-processors) and to not add an extra turbulence in the CI and verification results (as a part of the aforementioned port we have quite some re-work of the existing code for better co-existence of ARCv2 & ARcv3 ports) we decided to postpone a bit this change of compiler options.

So stay tuned and I hope to get this one addresses soon as well and do that right before v2.6 code freeze later this May.

@ruuddw
Copy link
Member

ruuddw commented May 26, 2021

@jacoba-at please see #35415, instead of -mcpu=hs38 that uses -mcpu=archs, which has the same effect.
ok to close this once that PR gets merged?

@jacoba-at
Copy link
Author

jacoba-at commented May 26, 2021 via email

@galak galak closed this as completed May 27, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area: ARC ARC Architecture bug The issue is a bug, or the PR is fixing a bug priority: low Low impact/importance bug
Projects
None yet
Development

No branches or pull requests

6 participants