search for: liskov

...in an effort to get a quick win". So far I thought this was a > > discussion of ideas, methods to gather data, and potential pitfalls. > > > > > > Making use-def chains work differently based on the dynamic type of a > Value* is very problematic to me. It breaks the liskov substitution > principle and is likely to lead to widespread bugs. > > That's why I'm also wary of the idea of just having use lists empty > for certain types without any other special handling. However, I would > argue that if Value::use_begin() etc. contain an assertion tha...

...ps16 as the minimal size class and passes it when I'm compiling for -mips32 -nomips16 > The ARM tGPR register class is the same. It has no business showing up in non-Thumb code, but it is completely harmless when it does. > > My best advice to you is don't try to swim upstream. The Liskov substitution principle for register classes is deeply ingrained in the LLVM register allocators. > > /jakob > I guess I can just fix the problem with: if ((RC == &Mips::CPU16RegsRegClass) && !TM.getSubtargetImpl()->inMips16Mode()) RC = &Mips::CPURegsRegClass;

...inimal size class and passes it when I'm compiling for -mips32 -nomips16 >> The ARM tGPR register class is the same. It has no business showing up in non-Thumb code, but it is completely harmless when it does. >> >> My best advice to you is don't try to swim upstream. The Liskov substitution principle for register classes is deeply ingrained in the LLVM register allocators. >> >> /jakob >> > I guess I can just fix the problem with: > > if ((RC == &Mips::CPU16RegsRegClass) && > !TM.getSubtargetImpl()->inMips16Mode()) >...

...anges with unclear tradeoffs > made in an effort to get a quick win". So far I thought this was a > discussion of ideas, methods to gather data, and potential pitfalls. Making use-def chains work differently based on the dynamic type of a Value* is very problematic to me. It breaks the liskov substitution principle <https://en.wikipedia.org/wiki/Liskov_substitution_principle> and is likely to lead to widespread bugs. > > Instead, let’s break down the problems and fix them (the right way!) > > one at a time. For example, it seems that the thread agrees that the > &...

...w, it sees mips16 as the minimal size class and passes it when I'm compiling for -mips32 -nomips16 The ARM tGPR register class is the same. It has no business showing up in non-Thumb code, but it is completely harmless when it does. My best advice to you is don't try to swim upstream. The Liskov substitution principle for register classes is deeply ingrained in the LLVM register allocators. /jakob

On 05/14/2012 02:17 PM, Jakob Stoklund Olesen wrote: > On May 14, 2012, at 1:02 PM, reed kotler wrote: > >> Does anyone understand the purpose of : >> >> TargetRegisterInfo::getMinimalPhysRegClass ??? > Barely. > >> Why is there the presumption to use the minimal subclass? > The function can be traced back to a time when men were men and registers belonged to

Jakob Stoklund Olesen <jolesen at apple.com> writes: > These sub-registers are special, they are only mentioned here: > > let CompositeIndices = [(sub_ss), (sub_sd)] in { > def XMM0: Register<"xmm0">, DwarfRegNum<[17, 21, 21]>; > def XMM1: Register<"xmm1">, DwarfRegNum<[18, 22, 22]>; > ... I'm confused. Below you

All, I've been trying to simplify the way LLVM models sub-register relationships a bit, and the X86 sub_ss and sub_sd sub-register indices are getting in the way. I want to get rid of them. These sub-registers are special, they are only mentioned here: let CompositeIndices = [(sub_ss), (sub_sd)] in { def XMM0: Register<"xmm0">, DwarfRegNum<[17, 21, 21]>; def

...r coalescer removes a copy between VR128 and FR64 registers, it chooses the larger spill size for the result. This is the same for sub-register copies and full register copies. The important point here is that VR128 is a sub-class of FR64, so getCommonSubClass(VR128, FR64) -> VR128. This is the Liskov substitution principle for register classes. /jakob

> On Mar 26, 2020, at 8:26 AM, Doerfert, Johannes <jdoerfert at anl.gov> wrote: > > On 3/26/20 5:53 AM, Florian Hahn wrote: >>> It also doesn't solve the problem of Functions themselves -- those are >>> also GlobalValues… >> >> >> I am not sure why not. Function passes should only rely on the information at the callsite & from the

I wrote this abomination just now, and wonder if anyone else has had experience with the pattern behind it. In short, I''m specing an after_create hook on an ActiveRecord model, that calls a bunch of private methods. Instead of stubbing all those private methods (which is verboten anyway, as well as impossible because creating the object which owns those methods is what I''m

On Jun 18, 2012, at 4:36 PM, Michael Spencer wrote: >>>> >>>> In asking around for clean models on how to do this better, I've heard two interesting ideas: >>>> >>>> 1) Incorporate the error_code and string message into the File class. That is the factory method always returns a File object. But there is a method on File objects to query if