Re: [2/5] C-SKY port: Backend implementation

[Jeff Law <law@redhat.com>]

On 07/24/2018 12:18 PM, Sandra Loosemore wrote:
> On 07/24/2018 09:45 AM, Jeff Law wrote:
>> On 07/23/2018 10:21 PM, Sandra Loosemore wrote:
>>> 2018-07-23  Jojo  <jijie_rong@c-sky.com>
>>>              Huibin Wang  <huibin_wang@c-sky.com>
>>>              Sandra Loosemore  <sandra@codesourcery.com>
>>>              Chung-Lin Tang  <cltang@codesourcery.com>
>>>
>>>          C-SKY port: Backend implementation
>>>
>>>          gcc/
>>>          * config/csky/*: New.
>>>          * common/config/csky/*: New.
>>
>> Let's avoid gratutious whitespace that attempts to line up conditionals.
>>    As an example, look at the predicate csky_load_multiple_operation.  I
>> think just doing a quick pass over the .c, .h and main .md files should
>> be sufficient here.
> 
> OK, will do.
> 
>> I'm not a big fan of more awk code, but I'm not going to object to it :-)
>>
>> Why does the port have its own little pass for condition code
>> optimization (cse_cc)?  What is it doing that can't be done with our
>> generic optimizers?
> 
> This pass was included in the initial patch set we got from C-SKY, and
> as it didn't seem to break anything I left it in.  Perhaps C-SKY can
> provide a testcase that demonstrates why it's still useful in the
> current version of GCC; otherwise we can remove this from the initial
> port submission and restore it later if some performance analysis shows
> it is still worthwhile.
FWIW it looks like we model CC setting on just a few insns, (add,
subtract) so I'd be surprised if this little mini pass found much.  I'd
definitely like to hear from the csky authors here.

Alternately, you could do add some instrumentation to flag when it
triggers, take a test or two that does, reduce it and we can then look
at the key RTL sequences and see what the pass is really doing.

> 
>> Any thoughts on using the newer function descriptor bits rather than old
>> style stack trampolines?
> 
> Has that been committed?  I vaguely remembered discussion of a new way
> to handle nested functions without using the trampoline interface, but I
> couldn't find any documentation in the internals manual.
It did.  See TARGET_CUSTOM_FUNCTION_DESCRIPTORS and the (relatively few)
ports that define it.



> 
>> I don't see anything terribly concerning in the core of the port.  The
>> amount of support code for minipool is huge and I wonder if some sharing
>> across the various ports would be possible, but I don't think that
>> should be a blocking issue for this port.
> 
> Yes, that code was clearly copied almost verbatim from the ARM backend.
> I left it alone as much as possible to simplify any future attempts at
> genericizing it.
Understood -- I'd assumed it was largely copied from ARM, but hadn't
gone back to the ARM bits to verify.

> 
>> Can you update the backends.html web page here appropriately for the
>> c-sky target?
> 
> Sure, I can take care of updating that when the port is committed.  I
> believe the right entry is
> 
> "csky                          b   ia"
Yea, that seems right to me.

Jeff