[prev in list] [next in list] [prev in thread] [next in thread] 

List:       pcc-list
Subject:    Re: [Pcc] Fwd: Re:  optim.c
From:       Tim Kelly <gtkelly () dialectronics ! com>
Date:       2017-05-19 12:13:52
Message-ID: 591EE180.5060905 () dialectronics ! com
[Download RAW message or body]

Regretfully, Peter did not have my permission to post my off-line 
statements to the list.  I re-iterate that I do not speak for the 
developer community, only as a (heavy) user of pcc.

Peter Kuschnerus wrote:
> 
> -------- Forwarded Message --------
> Subject: Re: [Pcc] optim.c
> Date: Fri, 19 May 2017 12:07:33 +0200
> From: Peter Kuschnerus <peter.kuschnerus@gmx.de>
> To: Tim Kelly <gtkelly@dialectronics.com>
> 
> Hi Tim
> 
> While I think that all your sugestions are well,
> my opinion is, that the state of the patch now is,
> to be reviewed.
> Before we considere to get this patch into the tree,
> I would like to get comments about what I did wrong
> and what I could do better.
> I invite everybody to review what I have done.
> Of course this should be done by ones that are familiar with that code.
> 
> Your concerns about RISC capabilities are surprising to me.
>  From the point of view of compilor writers
> the theorie of generating code for RISC is not different
> than for any other architectures.
> The main difference is that RISC uses larger sets of registers.
> Small register sets need good algorithms for register allocation.
> While on large register sets, this is less important.
> PCC has now a most advanced algorithm for register allocation,
> wich is most effective on arch like the Intel x86.
> So RISC has not more needs, but less need to the code generator.
> 
> Effords to optimize, allways spend extra compilation time,
> to generate faster code (I do not know any exeption).
> 
> IMHO patches that are contributed to PCC are to be covered by
> the same license as the PCC itself.
> There is no intention to do different.
> 
> 
> Regards
> Peter Kuschnerus
> 
> 
> On 18.05.2017 14:58, Tim Kelly wrote:
>> cc: Ragge
>>
>> Hi Peter,
>> I can not speak for the developer community, but as a user of pcc, my
>> concerns about the patch would center around introducing compiler
>> errors.  One thing I like about pcc is the documentation that pcc is
>> based on.  There are links to it on the pcc web site.  I'm not very
>> familiar with compiler theory, but I'd want to make sure that patches
>> are consistent with the documentation.  Unfortunately, the code itself
>> is not overly documented.  Documenting the code in your patches would be
>> something I as a user would appreciate.  Occasionally I do have to go
>> into the code and attempt to understand what is going on (I also have
>> plans to try to enhance the RISC capabilities of pcc).
>>
>> As a user of pcc, I would want to see that your code improves the
>> generated code.  While I have some interest in the speed of compilation,
>> I am primarily concerned about the speed of the object code.  This is
>> one area that I find pcc really outperforms gcc.
>>
>> My suggestion towards this would be to create some tests that show
>>
>> 1) your patch creates code as efficient as the original for all cases
>> 2) your patch reduces compilation time for all code
>> 3) your patch does not introduce potential compiler-based backdoors
>> 4) cases where your patch does not meet 1) and 2)
>>
>> Ideally 1) is "more efficient" but if 1) and 2) are both met that would
>> be an improvement.  If 1) were "more efficient" while 2) was not met
>> (longer compilation time), I would be satisfied that.  Compile once, run
>> many times.
>>
>> Additionally, as a user of pcc, I would want to know that the patches
>> came from original sources.  This is known as "provenance."  It might
>> help to be able to document how you came to these optimizations.  I'd
>> also want to know the patches are released under the same BSD license as
>> pcc.  I have personally undertaken a pretty hard effort to remove as
>> much GPL code as possible from my working environment, which includes
>> code that is inspired by GPL code.
>>
>> Again, I am not speaking for the developer community, who may have other
>> criteria.  I would be willing to test the patch if I knew the criteria
>> above above were satisfied.  Possibly having other pcc users test your
>> patch and verify 1-4) would help get your patch into the tree.  I do
>> have an interest in learning more about pcc and helping it along,
>> including understanding how to do regression tests and the like on 
>> changes.
>>
>> tim
>>
>> Peter Kuschnerus wrote:
>>> Hallo
>>>
>>> I tested selfprepared test to check each mew feature
>>> to satisfy myself that the code does as expected.
>>> But I agree that more tests should be done.
>>>
>>> Regards
>>> Peter Kuschnerus
>>>
>>>
>>> On 16.05.2017 20:28, Tim Kelly wrote:
>>>> Hi Peter,
>>>> I an not a pcc developer, but I asked Ragge if he had looked at your
>>>> code.  He said no, and he is very behind with his work, as he was quite
>>>> sick in April.  It may be a while, but he was not concerned about side
>>>> effects of discarding subtrees, so that would be a positive.
>>>>
>>>> There are some tests in pcc-tests.  Have you run them against your new
>>>> code?
>>>>
>>>> tim
>>>>
>>>> Peter Kuschnerus wrote:
>>>>> Hello
>>>>>
>>>>> I did review the code of optim.c in pass1.
>>>>> And I found that there are several obvious possible optimisations
>>>>> that are omitted.
>>>>> Most of these optimisations would cause to discard a subtree.
>>>>> Discarding subtrees is never done in this module.
>>>>> Discarding subtrees has the problem with possible side effects,
>>>>> which must be handeled.
>>>>> Now I implemented several additional optimisations.
>>>>> To handle possible side effects, I used the method of inserting
>>>>> a COMOP-operation, and let the cleanup be done later in pass2.
>>>>>
>>>>> I tested an updated version of optim.c.
>>>>> And it seems to work well.
>>>>>
>>>>> Now I like to present this version.
>>>>> As I am not a member of this team,
>>>>> I send this patch for further review and test.
>>>>> This patch was created by
>>>>> "diff -u optim.c optim.c.new >optim.c.patch"
>>>>> It can be applied by "patch optim.c optim.c.patch"
>>>>>
>>>>> This patch is attached to this mail.
>>>>>
>>>>>
>>>>> Regards
>>>>> Peter Kuschnerus
>>>>>
>>>>>
>>>>> ------------------------------------------------------------------------ 
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Pcc mailing list
>>>>> Pcc@lists.ludd.ltu.se
>>>>> https://lists.ludd.ltu.se/cgi-bin/mailman/listinfo/pcc
>>>>
>>
> _______________________________________________
> Pcc mailing list
> Pcc@lists.ludd.ltu.se
> https://lists.ludd.ltu.se/cgi-bin/mailman/listinfo/pcc

-- 
"You'll never understand unless you suffer some."
		-- Ritchie Kotzen
_______________________________________________
Pcc mailing list
Pcc@lists.ludd.ltu.se
https://lists.ludd.ltu.se/cgi-bin/mailman/listinfo/pcc
[prev in list] [next in list] [prev in thread] [next in thread]

Configure | About | News | Add a list | Sponsored by KoreLogic