Path: csiph.com!weretis.net!feeder6.news.weretis.net!news.misty.com!news.iecc.com!.POSTED.news.iecc.com!nerds-end From: Kaz Kylheku <480-992-1380@kylheku.com> Newsgroups: comp.compilers,comp.arch Subject: Re: Assembling span-dependent instructions Followup-To: comp.compilers Date: Fri, 29 Jul 2022 22:36:03 -0000 (UTC) Organization: A noiseless patient Spider Lines: 53 Sender: news@iecc.com Approved: comp.compilers@iecc.com Message-ID: <22-07-060@comp.compilers> References: <22-07-049@comp.compilers> <22-07-052@comp.compilers> <22-07-055@comp.compilers> Injection-Info: gal.iecc.com; posting-host="news.iecc.com:2001:470:1f07:1126:0:676f:7373:6970"; logging-data="48733"; mail-complaints-to="abuse@iecc.com" Keywords: code, optimize Posted-Date: 29 Jul 2022 19:01:02 EDT X-submission-address: compilers@iecc.com X-moderator-address: compilers-request@iecc.com X-FAQ-and-archives: http://compilers.iecc.com Xref: csiph.com comp.compilers:3147 comp.arch:76965 ["Followup-To:" header set to comp.compilers.] On 2022-07-28, antispam@math.uni.wroc.pl wrote: > In comp.arch Kaz Kylheku <480-992-1380@kylheku.com> wrote: >> On 2022-07-27, Anton Ertl wrote: >> > However, one can also construct cases where making the code larger can >> > reduce the minimum size of the immediate operand, e.g.: >> > >> > foo: >> > movl foo+133-bar(%rdi),%eax >> > bar: >> >> That's weird; what is accessed this way, relative to the code, >> and does it occur in compiler output? > > Code like this may appear due to alignment, say jump to page or cache > line boundary. In realistic situation one is faced in much more > compilex problem. Namely on many architectures best way to provide > constant arguments is by storing constants in memory. This leads to > "constant pools" and problem where to place them. One wants constant > pools as close as possible to code, to use short offsets accessing > them. But for performance reasons it is desirable to put constants in > separate cache lines. Also, one needs jumps to jump around constant > pools. Some jumps occur naturally in program, it is good to re-use > them. But there are possible unused parts of cache lines (both for > code and constant pools). So there is need to balance loss due to > unused parts of cache lines (probably dominant factor), length of > instructions and possible overhead due to extra instructions. OK; so that makes sense. Say we have a program segment with some PC relative references to a cache-aligned constant pool which is farther down the program. If this program segment shrinks, while the cache-aligned constant pool stays where it is (to remain aligned), then that pool will be farther away from some of those instructions. This could even happen due to smaller alignments like 8 bytes. Some instruction loses 4 bytes; then another one experiences the data being 4 bytes farther than before, which now doesn't fit. > There is extra complication when machine has limited range of offsets > which can be used in single intstruction: when needed offset exceeds > allowed range one has to change to indirect form which needs free > register. So there is extra interaction with registes allocation. On an architecture that is not so register starved, you just dedicate a register for that. MIPS calls it "at" ("assembler temporary"). -- TXR Programming Language: http://nongnu.org/txr Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal