mbox series

[v2,0/7] RISC-V/gas: insn operand parsing

Message ID ba68222c-7de6-280d-e98e-503e3c27addc@suse.com
Headers
Series RISC-V/gas: insn operand parsing |

Message

Jan Beulich March 10, 2023, 9:23 a.m. UTC 
  (v1 series was "re-work register named symbols avoidance logic")

This addresses some of the anomalies I've observed. There continue to
be questions towards consistent overall behavior - see remarks in the
individual patches.

An assembler with the full series in place was used in a gcc 12.2.0
testsuite run (cross build on x86, so no execution tests), resulting
in no new test failures (there were a number of pre-existing ones,
though).

1: minor effort reduction in relocation specifier parsing
2: drop "percent_op" parameter from my_getOpcodeExpression()
3: avoid redundant and misleading/wrong error messages
4: don't recognize bogus relocations
5: relax post-relocation-operator separator expectation
6: test for expected / no unexpected symbols
7: adjust logic to avoid register name symbols

Jan

Comments

Nelson Chu April 25, 2023, 8:40 a.m. UTC | #1 
Hi Jan,

On Fri, Mar 10, 2023 at 5:24 PM Jan Beulich <jbeulich@suse.com> wrote:

> (v1 series was "re-work register named symbols avoidance logic")
>
> This addresses some of the anomalies I've observed. There continue to
> be questions towards consistent overall behavior - see remarks in the
> individual patches.
>
> An assembler with the full series in place was used in a gcc 12.2.0
> testsuite run (cross build on x86, so no execution tests), resulting
> in no new test failures (there were a number of pre-existing ones,
> though).
>
> 1: minor effort reduction in relocation specifier parsing
> 2: drop "percent_op" parameter from my_getOpcodeExpression()
> 3: avoid redundant and misleading/wrong error messages
> 4: don't recognize bogus relocations
> 5: relax post-relocation-operator separator expectation
>

Except this one I'm not sure if we should accept or not, others look good
to me.  The gcc/binutils regressions of riscv-gnu-toolchain looks good with
this whole series, including the fifth patch, so I guess that is because
the current codegen and inline assembly developers are all expect () after
the %hi/%pcrel_hi/... modifiers.  I don't know if we should relax the usage
of modifiers here, but at least the regressions prove that there should be
no effect for now, even if we commit the patch.  The only thing is that we
may have different behaviors as llvm, but since llvm only accepts the ()
after the modifiers, we have already behaved a little differently.

Thanks
Nelson


> 6: test for expected / no unexpected symbols
> 7: adjust logic to avoid register name symbols
>
> Jan
>