This is an archive of the discontinued LLVM Phabricator instance.

[MSP430][Clang] Update hard-coded MCU data
Needs ReviewPublic

Authored by jozefl on Aug 18 2021, 7:24 AM.

Details

Reviewers
asl
atrosinenko
Summary

This patch updates MSP430 MCU data to the latest version distributed by
TI, adding support for 451 additional MCUs.

The hardware multiply version supported by each MCU is now stored as an
enum in the MCU data file, rather than a string. The string value passed
to the -mhwmult= option is now also converted to an enum. Using an enum
simplifies the processing of values, as invalid user input can be
canonicalized as a descriptive enum. It also ensures that the hard-coded
MCU data is valid; that there are no values that the parser does not
recognize.

Clang will no longer explicitly disable hwmult features for MCUs that
don't have hardware multiply support, as hwmult feature are already
disabled by default.

The CPU version of each MCU is now stored with the hard-coded MCU data,
so Clang can enable the appropriate LLVM CPU features when a particular
MCU is selected.

The hard-coded MCU data is stored in lexicographic order, which enables
efficient searching of the data with binary search, using
std::lower_bound.

If the patch is acceptable, I would appreciate it if someone would apply
it for me, as I do not have commit access.

Thanks,
Jozef

Diff Detail

Event Timeline

jozefl requested review of this revision.Aug 18 2021, 7:24 AM
jozefl created this revision.
Herald added a project: Restricted Project. · View Herald TranscriptAug 18 2021, 7:24 AM
Herald added a subscriber: cfe-commits. · View Herald Transcript
jozefl updated this revision to Diff 367458.Aug 19 2021, 4:38 AM

Fixed clang-tidy warnings.

Now that I am in the process of implementing the processing of the "CPU"
feature, I've realized the decision to store the CPU and HWMult information as
enums instead of strings has some downsides that may outweigh the benefits:

  • All string values passed to options need to be first converted to enums before they can be processed
  • Enums need to be converted back to strings in for use in diagnostics
  • Additional code is required to perform these conversions

If all CPU and HWMult features are stored as strings, no conversions are
necessary, and the overall amount of code that needs to change for this MCU
data update is small.

As mentioned in the original commit message, the benefits of using enums are
that we have a canonical "invalid" value for when the user input is invalid,
and the hard-coded data is guaranteed to be valid (but not necessarily
correct) since all enums used to define features must be defined.

The processing of the CPU feature is much simpler than the hwmult features,
which is why all the conversions to and from enums seem even more unnecessary
now.

What do you think @asl? Should I get rid of the enums?
That is was I'm leaning towards right now.

Thanks,
Jozef

jozefl updated this revision to Diff 367739.Aug 20 2021, 2:06 AM

Here's an updated patch that stores the HWMult and CPU data for each MCU as
strings instead of enums. This simplifies the patch as string conversions to
and from enums are no longer required.

jozefl updated this revision to Diff 367805.Aug 20 2021, 9:15 AM

Here's an updated patch to fix the win64 failure.

MSVC can't handle the conversion from a ForwardIterator to a const pointer when
the container being searched with std::lower_bound is a std::array. Meanwhile
clang-tidy warns when the type assigned to with the return value of
std::lower_bound is not a pointer, so I can't just change the type declaration
to a lone "auto", and surpressing the clang-tidy warning for this warning
doesn't seem like the best option either.

So I've changed the data type used to store the MCUData to a C-style array, and
also moved its definition into loadMCUData.

jozefl updated this revision to Diff 368348.Aug 24 2021, 8:02 AM

Here's an updated patch that fixes some minor nits.

Pinging for review.

Thanks,
Jozef

Pinging for review.

Thanks,
Jozef

jozefl updated this revision to Diff 374200.Sep 22 2021, 6:14 AM

Rebase to fix patch application failure for
clang/test/Misc/target-invalid-cpu-note.c.

Herald added a project: Restricted Project. · View Herald TranscriptSep 22 2021, 6:14 AM
jozefl updated this revision to Diff 374255.Sep 22 2021, 9:13 AM

Undo incorrect rebase.

asl requested changes to this revision.Sep 28 2021, 10:55 AM

Please see comments inline

clang/lib/Driver/ToolChains/MSP430.cpp
43

maybe it would be better to use get instead of load here?

44

Can we simply use MSP430MCUData[] here in order not to fix multiple places when new MCU is added?

47

I'd also #undef here for the sake of not polluting everything with extra macros

77

Features is effectively an output argument here. Can it be last argument? Maybe it would be better to name addHWMultFeatures, overall the function just adds them and do not touch existing things in the Features vector?

110

StringSwitch?

This revision now requires changes to proceed.Sep 28 2021, 10:55 AM
jozefl updated this revision to Diff 375666.Sep 28 2021, 12:35 PM
jozefl marked 5 inline comments as done.

Thanks, good points, I have addressed them in this updated patch.

jozefl added a comment.Oct 4 2021, 7:51 AM

Ping.

Thanks,
Jozef

jozefl updated this revision to Diff 379011.Oct 12 2021, 6:30 AM

Rebase onto new base revision to fix pre-merge tests.

Ping.

Thanks,
Jozef

Ping.

Thanks,
Jozef

Ping.

Thanks,
Jozef

krisb added a subscriber: krisb.Dec 2 2021, 4:35 AM
krisb added inline comments.
clang/lib/Driver/ToolChains/MSP430.cpp
248–249

It might be worth moving this under hwmult option check, so we do not need to load MCU data again if the option is properly specificed.

jozefl updated this revision to Diff 392071.Dec 6 2021, 8:08 AM
jozefl marked an inline comment as done.

Thanks, good point, fixed in the attached patch.

ormris removed a subscriber: ormris.Jan 24 2022, 11:13 AM