bug#42147: 28.0.50; pure vs side-effect-free, missing optimizations?

[Andrea Corallo]

Mattias Engdegård <mattiase@acm.org> writes:

> 1 juli 2020 kl. 23.31 skrev Andrea Corallo <andrea_corallo@yahoo.it>:
>
>> Another reason why I'm interested is that I reuse these
>> definitions in the native compiler.
>
> In that case there are probably more functions you may want to consider for 
> purity -- what about:
>
> < > <= >= = /=
> string< string= string-equal
> eq eql equal
> proper-list-p
> identity
> memq memql member
> assq assql assoc

Good point

>> I guess for the most part I can just include the one I've missed.
>
> By all means, but do not take my word for the correctness of my list -- think 
> it through yourself. We mustn't err here.
>
>> I'm not only sure about the one operating on lists like `length' given the
>> list may be modified in the runtime (?).
>
> Not sure why this would be an obstacle, but I could have overlooked
> something important! Could you explain your thinking in greater
> detail, and if possible provide an example of code that you think
> might be miscompiled if 'length' or 'safe-length' were marked pure?

No, thinking about I believe you are correct.

I mixed in mind the fact that now the native compiler must handle
correctly in the CFG also pure functions taking mutable objects (given we
are adding them), but that is unrelated.  This is no problem for the
bytecompiler given the constant folding is done only locally.

So yes these are pure functions and so they should be marked.

> I still wonder if there is any reason to limit arithmetic constant
> folding to the portable fixnum range. Given that we don't evaluate
> fixnump or bignump at compile-time, what observable effects would
> constant-folding, say, (ash 1 32) have? Advice from deeper thinkers
> solicited!

I always thought the general idea is to respect the allocation side
effect we have creating a bignum.  Not sure if the class of example you
have in mind here fits this case.

Thanks

  Andrea