Path: utzoo!attcan!uunet!cs.utexas.edu!sdd.hp.com!uakari.primate.wisc.edu!dali.cs.montana.edu!milton!uw-beaver!rice!titan.rice.edu!preston From: preston@titan.rice.edu (Preston Briggs) Newsgroups: comp.arch Subject: Re: Compilers taking advantage of architectural enhancements Message-ID: <1990Oct12.153627.12367@rice.edu> Date: 12 Oct 90 15:36:27 GMT References: <1990Oct11.223224.26604@rice.edu> Sender: news@rice.edu (News) Organization: Rice University, Houston Lines: 82 In article aglew@crhc.uiuc.edu (Andy Glew) writes: >>>Perhaps we can start >>>a discussion that will lead to a list of possible hardware >>>architectural enhancements that a compiler can/cannot take advantage of? >However, if it's only just now being published, that probably means >its leading edge, so a company should not design for this unless it >has guys in its compiler group actually working on it. > Any comment on this way of looking at it? Tough call. It's hard to get people to look seriously at imaginary machines, especially when there's so many real machines (with real problems:-). >>>Heterogenous register file >>> Few compilers have been developed that can take advantage of a >>> truly heterogenous register file, one in which, for example, the >>> divide unit writes to registers D1..D2, the add unit writes to >>> registers A1..A16, the shift unit writes to registers S1..S4 -- >>> even though such hardware conceivably has a cycle time advantage >>> over homogenous registers, even on VLIW machines where data can >>> easily be moved to generic registers when necessary. >>> DIFFICULTY: hard. >> >>At first glance, the problem seems susceptable to coloring. >Here's one example: the Intel 80x86 is basically a heterogenous >register file machine. Specific registers were tied to the outputs and >inputs of specific functional units in the original hardware. >Compiler people hated targetting this architecture, and there are very >few compilers that can produce machine code comparable to hand-coded >assembly on this architecture. > >But heterogenous register files are much easier to make fast. I think >that two things can be done to make them easier for the compilers to >use: > (1) Provide more than one register at the output of any specific > functional unit. This avoids the need to immediately move > the result away. > (if my spelling is bad it's because my keyboard just went flakey) > (2) Make the register file heterogenous for writes, but homogenous > for reads (it's easier to provide read multiporting than > write multiporting). I'm not sure how to "fix" the x86 family. Your ideas seem good. Additionally, a larger total register file helps avoid ugly spill code. I expect, on the x86, humans do a better job than coloring allocators because humans can rearrange the code and a coloring allocator normally sticks with the schedule it's handed. Careful intermediate code generation in the front end can help, but it seems a difficult problem. >>>Special hardware instructions - scalar >>> Taking advantage of simple instructions like abs(), conditional >>> exchange, etc. >>> DIFFICULTY: >>> (1) When treated not as a compiler problem, but as a problem of simply >>> writing libraries to inline optimized machine code, EASY >>> Requires inlining support. >>That is, have intermediate language instructions >>for ABS etc. so the optimizer can try and hoist them or perhaps strength >>reduce them (e.g. SIN). Then expand to a simple form (perhaps with branches >>and so forth), and let the optimizer get at the guts of each operation. >>Some like ABS might be available as basic instructions and so need not >>be expanded to a lower level form. This seems to require that the >>front-end recognize certain calls as intrinsics. >I'm a fan of GNU EMACS style inlining. I don't think that your >intermediate language should even attempt to represent all of the >special hardware instructions that are likely to be useful I was really advocating having (roughly) an IL instruction for every source language instrinsic. That is, I didn't have an aswer for your question, so I made up my own. -- Preston Briggs looking for the great leap forward preston@titan.rice.edu