RE: [PATCH, MIPS] Ensure default ASEs are applied for an architecture

["Maciej W. Rozycki" <macro at imgtec dot com>]

On Wed, 22 Mar 2017, Matthew Fortune wrote:

> >  I still think we don't want to have an extra `init_ase' member only used
> > once.  I think we should reinstate the global `file_ase' variable removed
> > with commit 919731affbef (and complementing `file_ase_explicit' still
> > present there) and adjust the API of `mips_set_ase' so that it operates on
> > `unsigned int *ase_flags' instead of `struct mips_set_options *opts', and
> > then adjust call sites accordingly to refer to `&file_ase' or
> > `&mips_opts.ase' as appropriate.  Then in `file_mips_check_options':
> > 
> >    file_mips_opts.ase &= ~file_ase_explicit;
> >    file_mips_opts.ase |= file_ase;
> > 
> > will do.  Can you implement this?
> 
> I'll need to think about this more as although initially I thought your
> proposal was going to clean up the solution it has some issues. The main one
> being that file_ase, if re-introduced, must be used only to track the ASEs
> coming from the selected arch not the explicitly selected ASEs.  This is
> because the logic needed in file_mips_check_options is to set up the
> overall ASEs to be anything that was explicitly selected and bits from the
> architecture ASEs that were not explicitly disabled.

 I've meant the opposite arrangement, that is `file_ase' to hold the 
explicitly selected ASEs (further masked by `file_ase_explicit' so that 
both binary states are recorded), not any taken from the architecture.  
That would be achieved by making `mips_set_ase' operate on `&file_ase' in 
`md_parse_option' and on `&mips_opts.ase' elsewhere.

>  In the long run, and
> to some extent just to solve this issue, we are going to want to track all
> of:
> 
> 1) Which ASEs have been explicitly enabled/disabled
> 2) Which ASEs are enabled overall
> 3) Which ASEs the chosen architecture enables by default
> 
> This data is needed on a global and per .push stack level to calculate the
> appropriate ASEs at any given time. (1) needs a new mips_set_options field
> and the global file_ase_explicit moving to file_mips_opts.ase_explicit. (2)
> is mips_set_options 'ase' field. (3) would be a new field but could actually
> be implemented by removing 'arch' and 'isa' from mips_set_options and instead
> just keeping a reference to the mips_cpu_info entry for the selected arch
> which would then get the ASE list for free. (this also solves the name issue
> for warnings and errors).
> 
> I believe this scheme would also directly help with having .set arch affect
> the ASEs as you indicated should be done with follow up work.

 I think any further work on `.set arch=...' should make it just override 
all ASEs as per the architecture selected, ignoring any command-line 
selection.  Any other ASEs required or unwanted by the piece covered by 
`.set arch=...' would have to be controlled by further `.set' pseudo-ops 
that follow.  That goes along with the purpose of `.set arch=...', that is 
to have a piece of code assembled for the architecture selected rather 
than the global settings.  Of course `.set pop' will then restore any 
previous ASE selection.

 AFAICT the only reason why we need the extra complication for ASEs 
explicitly selected on the command line is because we don't process 
command-line options fully in the order they appear on the command line, 
and instead have a complex set of rules, where e.g.: `-mmt -mno-mt' keeps 
the MT ASE disabled as one would expect, but also both `-mno-mt 
-march=34kc' and `-march=34kc -mno-mt' do (barring this regression) while 
one might expect only the latter to, and say `-march=4kc -march=34kc' 
issues a warning rather than silently assuming the `4kc' architecture has 
simply been overridden with `34kc'.

 We don't have this issue with `.module' or `.set' pseudo-ops as they are 
simply interpreted in the order they appear in the source.

  Maciej