GNU bug report logs - #42147
28.0.50; pure vs side-effect-free, missing optimizations?

Previous Next

Full log

View this message in rfc822 format

From: Mattias Engdegård <mattiase <at> acm.org>
To: Andrea Corallo <andrea_corallo <at> yahoo.it>
Cc: Paul Eggert <eggert <at> cs.ucla.edu>, Stefan Monnier <monnier <at> iro.umontreal.ca>, 42147 <at> debbugs.gnu.org
Subject: bug#42147: 28.0.50; pure vs side-effect-free, missing optimizations?
Date: Thu, 2 Jul 2020 14:46:47 +0200

2 juli 2020 kl. 12.59 skrev Andrea Corallo <andrea_corallo <at> yahoo.it>:

>> 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.

Number allocation isn't a semantically visible effect and we probably don't want to change that. As far as I can tell, only fixnump and bignump can discriminate fixnums from bignums. There may be functions that only accept fixnums as arguments and thus fail with a different error, but I don't think we constant-fold any of them, and they would be easy to fix if we did.

It may be preferable to defer generation of very big numbers to run-time, to avoid evaluation of (ash 1 1000) at compile-time, but  such a limit should, if implemented, be independent of the fixnum limit (and likely higher).

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.