asb added a comment.
In https://reviews.llvm.org/D45284#1074282, @apazos wrote:
> Hi Alex, it seems the table expects these extensions in a canonical order
> too: all x extensions, followed by all s extensions, and then all sx
> extensions.
>
> I can make the change, no problem. I have also coded other error situations
> described below.
>
> But f I cannot push a test we can enable, because we error out when we find
> the first non-supported extension in the string with unsupported extension
> message, and stop parsing the string.
In the best case we would first parse the string and give errors based on the
string being malformed before determining which extensions the compiler
supports and complaining if the extension is not supported. This would probably
move us towards a two-pass scheme where structs are are generated from the
string, (parsing stage) which are then processed. e.g. `{ enum ExtType Type;
StringRef name; int MajorVersion; int MinorVersion; }`. The parser can issue
errors encountered when extracting this struct (e.g. malformed version
identifiers), including erroring if the ordering of the ExtType relative to the
previous ExtType is unexpected. The next step is complaining about semantic
issues (clashing extensions or extensions with missing dependencies) as well as
extensions that aren't supported.
However I realise that might be a larger refactoring. This is already the most
complete RISC-V ISA string parser in existence (as far as I know), which goes
some way beyond our near-term requirements. I'd be happy to merge this current
version and evolve it in-tree if you prefer, or of course I'll happily review
further updates to this patch.
https://reviews.llvm.org/D45284
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
