[wwwdocs] SH 4.8 changes update

On Sun, 2012-08-19 at 19:20 +0200, Gerald Pfeifer wrote:
> On Sun, 19 Aug 2012, Oleg Endo wrote:
> > This is what has been done so far on the SH side for 4.8.
> > I hope it's OK.
> 
> Wow, that is quite impressive (and a nice write-up also)!

Thanks.  Let's hope that I can squeeze in some more stuff while stage 1
lasts. :T

> I see this was already approved, but allow me to suggest some
> minor editorial comments...

Thanks for those!  Since I've just committed the thing as it was, please
find the correcting patch in the attachments.

> 
> Index: htdocs/gcc-4.8/changes.html
> ===================================================================
> +    <li>The default alignment settings have been reduced to be less aggresive.
> 
> "aggressive"

Fixed.

> +      <li>Minor tweaks for code around software atomic sequences that are
> +      enabled by <code>-msoft-atomic</code>.</li>
> 
> "code for"?  Not sure...

Rephrased.

> +      <li>A new option <code>-menable-tas</code> will make the compiler
> +      generate the <code>tas.b</code> instruction for the
> +      <code>__atomic_test_and_set</code> built-in function.</li>
> 
> A naive question: Why is this not on by default?  Or is it under
> certain circumstances?

SH's tas.b insn can potentially confuse caches under certain HW
configurations and result in data corruption.  Moreover, it flushes the
operand cache line for the variable in question and then does its thing.
There might be problems when it's used together with other ways of doing
atomics, so maybe it's better not to surprise people by enabling it by
default.
But now that you mention it, maybe it would be better to rename the
'-menable-tas' option to '-mtas', since other instruction related
options do not have 'enabled' in the name.

> +    <li>The <code>fmac</code> instruction will now be emitted by the
> +    <code>fmaf</code> standard and built-in function.</li>
> 
> "built-in standard function", perhaps?

Clarified.

> 
> +    <li>The <code>-mfused-madd</code> option has been depricated in favor of
> 
> "deprecated"

Fixed.

> +    <li>Added new options <code>-mfsrra</code> and <code>-mfsca</code> to allow
> +    the compiler using the <code>fsrra</code> and <code>fsca</code>
> +    instructions on CPUs other than SH4A.</li>
> 
> How about adding "...SH4A (where they are already on by default)" or
> similar?

Added.

OK to install?

Cheers,
Oleg

On Sun, 19 Aug 2012, Oleg Endo wrote:
> Thanks.  Let's hope that I can squeeze in some more stuff while
> stage 1 lasts. :T

You know that for backend-specific changes (especially for "smaller"
ports) you actually have some more leeway?

> But now that you mention it, maybe it would be better to rename the
> '-menable-tas' option to '-mtas', since other instruction related
> options do not have 'enabled' in the name.

Now still would be time to do so without worrying about compatibility. ;-)

> OK to install?

Oh, yes.  Thanks!

Gerald

On Sun, 2012-08-19 at 21:43 +0200, Gerald Pfeifer wrote:
> On Sun, 19 Aug 2012, Oleg Endo wrote:
> > Thanks.  Let's hope that I can squeeze in some more stuff while
> > stage 1 lasts. :T
> 
> You know that for backend-specific changes (especially for "smaller"
> ports) you actually have some more leeway?

You mean, since SH is neither a primary nor a secondary platform, there
are no particular release criteria for it?  What does that actually
mean?

> > But now that you mention it, maybe it would be better to rename the
> > '-menable-tas' option to '-mtas', since other instruction related
> > options do not have 'enabled' in the name.
> 
> Now still would be time to do so without worrying about compatibility. ;-)

True.

Cheers,
Oleg

On Mon, Aug 20, 2012 at 1:37 AM, Oleg Endo <oleg.endo@t-online.de> wrote:
> On Sun, 2012-08-19 at 21:43 +0200, Gerald Pfeifer wrote:
>> On Sun, 19 Aug 2012, Oleg Endo wrote:
>> > Thanks.  Let's hope that I can squeeze in some more stuff while
>> > stage 1 lasts. :T
>>
>> You know that for backend-specific changes (especially for "smaller"
>> ports) you actually have some more leeway?
>
> You mean, since SH is neither a primary nor a secondary platform, there
> are no particular release criteria for it?  What does that actually
> mean?

It means that release managers do not care about the state of the SH port.
It means SH target maintainers have to watch how the release goes and
decide when to put effort into testing and fixing bugs themselves, otherwise
they may run into the situation that the SH port does not even build for
the release.  So kind of target maintainers for ports that are not primary
or secondary are their own release managers without any control over
release timing.

Richard.