Re: [Chicken-hackers] [PATCH] Mostly fix #1604
felix.winkelm...@bevuta.com writes: >> > Interprocedural flow-analysis is hard, we shouldn't underestimate >> > this. What happens when we declare a type for a toplevel function? >> >> If you're thinking about reassigning globals, how about making >> -fixnum-arithmetic imply -local? If globals cannot be re-defined then >> the types are always correct. >> >> If fixnum-arithmetic is wanted for speed then -local is wanted anyway, >> not to mention global inlining. > > I understand - but I'm wary of options implying other options. This makes > it hard to figure out the final set of applicable settings, in the name of > convenience > I have made this mistake often enough. If one wants speed, "-O" is probably > the easiest and simplest way. Otherwise each option should have a single > effect only. Are you talking about deciding "what features should be enabled given this set of features is requested"? Using a simple dependency resolver with declarative dependencies makes that really nice: (add-option x implies: (y z) conflicts: (a b)) I used this kind of system for a toy code obfuscator many years ago when the conditional logic to do it in code got too hairy to follow. I think some of the options were internal and some could be given from command line. > > > felix ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-hackers
Re: [Chicken-hackers] [PATCH] Mostly fix #1604
On Mon, May 20, 2019 at 05:09:47PM +0200, felix.winkelm...@bevuta.com wrote: > > Note that Wasamasa pointed out on IRC that we still need to add -feature > > to chicken-install, which ties in nicely with cond-expand (see > > https://bugs.call-cc.org/ticket/1617) > > Isn't this already the case? (f701e594dd59b8ab4dc04d340e81440f84ae5d9a) You're right! I guess we both overlooked it. Cheers, Peter signature.asc Description: PGP signature ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-hackers
Re: [Chicken-hackers] [PATCH] Mostly fix #1604
> Note that Wasamasa pointed out on IRC that we still need to add -feature > to chicken-install, which ties in nicely with cond-expand (see > https://bugs.call-cc.org/ticket/1617) Isn't this already the case? (f701e594dd59b8ab4dc04d340e81440f84ae5d9a) felix ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-hackers
Re: [Chicken-hackers] [PATCH] Mostly fix #1604
On Mon, May 20, 2019 at 03:15:20PM +0200, felix.winkelm...@bevuta.com wrote: > > > Interprocedural flow-analysis is hard, we shouldn't underestimate > > > this. What happens when we declare a type for a toplevel function? > > > > If you're thinking about reassigning globals, how about making > > -fixnum-arithmetic imply -local? If globals cannot be re-defined then > > the types are always correct. > > > > If fixnum-arithmetic is wanted for speed then -local is wanted anyway, > > not to mention global inlining. > > I understand - but I'm wary of options implying other options. This makes > it hard to figure out the final set of applicable settings, in the name of > convenience > I have made this mistake often enough. If one wants speed, "-O" is probably > the easiest and simplest way. Otherwise each option should have a single > effect only. I agree; this sounds like it's making a lot of assumptions about exactly how the user wants to bend the Scheme semantics to make it faster. Cheers, Peter signature.asc Description: PGP signature ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-hackers
Re: [Chicken-hackers] [PATCH] Mostly fix #1604
> > Interprocedural flow-analysis is hard, we shouldn't underestimate > > this. What happens when we declare a type for a toplevel function? > > If you're thinking about reassigning globals, how about making > -fixnum-arithmetic imply -local? If globals cannot be re-defined then > the types are always correct. > > If fixnum-arithmetic is wanted for speed then -local is wanted anyway, > not to mention global inlining. I understand - but I'm wary of options implying other options. This makes it hard to figure out the final set of applicable settings, in the name of convenience I have made this mistake often enough. If one wants speed, "-O" is probably the easiest and simplest way. Otherwise each option should have a single effect only. felix ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-hackers
Re: [Chicken-hackers] [PATCH] Mostly fix #1604
felix.winkelm...@bevuta.com writes: >> > Shouldn't the types.db specialization for scheme#= be applied >> > here? Or can't it figure out the ffixnum types of the arguments? >> > Even though it is slightly dangerous, the scrutinizer _could_ assume >> > arguments to numerical primitives are fixnums in fixnum mode... >> >> That's right, the scrutinizer can't figure out the types. The type of n >> for the first scheme#= call is *. The call enforces the type to number. >> So the second scheme#= is called with (number fixnum). There's no >> specialization for that either. >> >> Wouldn't that kind of assuming lead to hard to debug bugs? > > Yes, that danger is indeed not to be ignored. > >> >> If the scrutinizer could infer types for functions then I think that >> would be fine. You'd get a warning somewhere. > > Interprocedural flow-analysis is hard, we shouldn't underestimate > this. What happens when we declare a type for a toplevel function? If you're thinking about reassigning globals, how about making -fixnum-arithmetic imply -local? If globals cannot be re-defined then the types are always correct. If fixnum-arithmetic is wanted for speed then -local is wanted anyway, not to mention global inlining. > > > felix ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-hackers
Re: [Chicken-hackers] [PATCH] Mostly fix #1604
On Mon, May 20, 2019 at 01:57:29PM +0200, felix.winkelm...@bevuta.com wrote: > > Besides, like I said in the other mail, then we'd still be calling > > allocating functions because (+ fixnum fixnum) => (or fixnum bignum). > > In fixnum mode, we'd want to use the overflowing unsafe fixnum ops. > > And I think that is a situation where assuming a specific type is ok, > or at least not dangerous. An overflow is less likely (especially on 64 > bit machines) and a weird result may be easier to track down. Agreed; when you enable fixnum mode, you're explicitly telling the compiler that you don't care about any of that stuff, you just want SPEED. That said, I think the patch as it stands is fine to apply. We can focus on fixing these other issues later (maybe in 5.2?), because it sounds like a much bigger undertaking to change how specialization in the scrutinizer works. AFAIK we want to get 5.1 out soonish so we have a version that has chicken-install with cond-expand. Note that Wasamasa pointed out on IRC that we still need to add -feature to chicken-install, which ties in nicely with cond-expand (see https://bugs.call-cc.org/ticket/1617) Cheers, Peter signature.asc Description: PGP signature ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-hackers
Re: [Chicken-hackers] [PATCH] Mostly fix #1604
> Besides, like I said in the other mail, then we'd still be calling > allocating functions because (+ fixnum fixnum) => (or fixnum bignum). > In fixnum mode, we'd want to use the overflowing unsafe fixnum ops. And I think that is a situation where assuming a specific type is ok, or at least not dangerous. An overflow is less likely (especially on 64 bit machines) and a weird result may be easier to track down. felix ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-hackers
Re: [Chicken-hackers] [PATCH] Mostly fix #1604
> > Shouldn't the types.db specialization for scheme#= be applied > > here? Or can't it figure out the ffixnum types of the arguments? > > Even though it is slightly dangerous, the scrutinizer _could_ assume > > arguments to numerical primitives are fixnums in fixnum mode... > > That's right, the scrutinizer can't figure out the types. The type of n > for the first scheme#= call is *. The call enforces the type to number. > So the second scheme#= is called with (number fixnum). There's no > specialization for that either. > > Wouldn't that kind of assuming lead to hard to debug bugs? Yes, that danger is indeed not to be ignored. > > If the scrutinizer could infer types for functions then I think that > would be fine. You'd get a warning somewhere. Interprocedural flow-analysis is hard, we shouldn't underestimate this. What happens when we declare a type for a toplevel function? felix ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-hackers
