search for: materialise

...code was ORing a value with 5 and the target only had OR-register and not OR-immediate. You would expect local code generation to handle OR-immediate by locally materialising the constant into a spare register. But if the usage was in a loop it would be better (at the cost of register pressure) to materialise 5 into a register outside of the loop and use the register repeatedly in the loop. Al -- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose th...

Hi, I'm planning to implement "execute only" support in the ARM code generator. This basically means that the compiler will not generate data access to the generated code sections (e.g. data and code are strictly separated into different sections). Outline: - Add the subtarget feature/attribute "execute-only" to the ARM code generator to enable the feature.

...n the former, you cannot know until load-time what the offset is between the code section and the data section is, whereas in the latter you’re using `gp` to keep the upper 32-bits of that offset to avoid materialising it in every access (if you statically linked, and we added enough relocations to materialise 64-bit immediates, you could materialise the offset everywhere. It would be inefficient, but not wrong). > > Is this a fair understanding, Evandro? > > Sam > >> On 20 Mar 2020, at 7:49 pm, Eli Friedman via llvm-dev <llvm-dev at lists.llvm.org> wrote: >> >>...

Oh, I wasn’t really thinking about devices without an MMU where the addresses are physically separated. Makes sense. This reminds me of rwpi on ARM; it has a sort of similar scheme of referring to data indirectly through a pointer, but it also changes the ABI to keep the pointer in a reserved register. -Eli From: Evandro Menezes <evandro.menezes at sifive.com> Sent: Friday, March 20, 2020

Hi, > Other than: > %x = add i32 5,0 ; suppose I want to assign 5 to %x > > is there any other way? Something like x86's mov instruction let me say that in general doing this is pointless. Due to SSA form, if %x is set to 5 you can't set it to something else later. Thus everywhere that you use %x you might as well just directly use 5 there instead. A common situation is

...gt; with 5 and the target only had OR-register and not OR-immediate. > You would expect local code generation to handle OR-immediate by > locally materialising the constant into a spare register. > But if the usage was in a loop it would be better (at the cost of > register pressure) to materialise 5 into a register outside of the > loop and use the register repeatedly in the loop. it is up to the code generators to take care of this kind of thing. I don't see how having (at the IR level) a register called %x which contains the value 5 makes it easier for the code generators to perfor...

> But if the usage was in a loop it would be better (at the cost of > register pressure) to materialise 5 into a register outside of the > loop and use the register repeatedly in the loop. Bouncing on this subject: you can not know before isel is over if the constants have to materialize into registers or not, as this is really dependent on the target's instruction set. Do we have any pass ho...

On Tue, Oct 19, 2010 at 12:19 AM, Arnaud Allard de Grandmaison <Arnaud.AllardDeGrandMaison at dibcom.com> wrote: >> But if the usage was in a loop it would be better (at the cost of >> register pressure) to materialise 5 into a register outside of the >> loop and use the register repeatedly in the loop. > > Bouncing on this subject: you can not know before isel is over if the constants have to materialize into registers or not, as this is really dependent on the target's instruction set. Do we hav...

> There's already a working fast isel port as well. Though I'm not sure > how well tested that's been on linux. > > Tim? I've not tested FastISel on Linux at all, I'm afraid. In theory I'd expect only minor modifications to be necessary (around global variable materialisation, if anywhere). Cheers. Tim.

...dent if the branch immediate value is > 0xffff then > the imm instruction should generate other wise only "br" instruction > is enough. This sounds as if you have two br instructions, one that takes an immediate and one that takes a register and requires that another instruction materialise the address in a register. This is common to most targets - you will find lots of examples in the code - but the high-level picture is to describe both variants in TableGen with appropriate constraints on the range of the immediate. SelectionDAG will pick the immediate version of the constraints...

Other than: %x = add i32 5,0 ; suppose I want to assign 5 to %x is there any other way? Something like x86's mov instruction -- View this message in context: http://old.nabble.com/How-to-assign-a-constant-to-a-register--tp29987387p29987387.html Sent from the LLVM - Dev mailing list archive at Nabble.com.

Quick and dirty: --- lib/facter.rb (revision 203) +++ lib/facter.rb (working copy) @@ -989,6 +989,18 @@ %x{/usr/sbin/scutil --get LocalHostName} end end + Facter.add(:interfaces) do + confine :kernel => :linux + setcode do + %x{/sbin/ifconfig -a -s}.split($/)[1..-1].collect {|line|

...for your case? It might work, although given that our fat pointers are not integers I'm not sure how you think we should represent them. We can represent them as i256, but that would be very misleading as they don't have the majority of integer operations defined on them, and we can't materialise a pointer from an integer, only from an existing pointer and an offset. We ideally want address operations to always be of the form base + offset, where the offset is in an integer register and moves, but the base is not. Currently, we are generating a lot of increment-base + load sequences and h...

On Fri, Mar 2, 2018 at 4:59 PM, David Chisnall <David.Chisnall at cl.cam.ac.uk> wrote: > On 2 Mar 2018, at 11:09, Nagaraju Mekala via llvm-dev <llvm-dev at lists.llvm.org> wrote: >> >> I am working on a target which requires to generated two >> instructions for a single branch instruction. >> ex: >> imm 1 >> br r4,0xabcd >> branch

On 16 Nov 2016, at 21:56, Daniel Berlin <dberlin at dberlin.org> wrote: > > You keep talking about platforms, but llvm ir itself is not platform dependent. > Can you give a reference in the language reference that says that this is not legal? Nothing in the LangRef (apart from the note about non-integral pointers, which was added recently) makes any claim about the representation

...ase? > > It might work, although given that our fat pointers are not integers I'm not sure how you think we should represent them. We can represent them as i256, but that would be very misleading as they don't have the majority of integer operations defined on them, and we can't materialise a pointer from an integer, only from an existing pointer and an offset. We ideally want address operations to always be of the form base + offset, where the offset is in an integer register and moves, but the base is not. Currently, we are generating a lot of increment-base + load sequences and h...

On Aug 9, 2013, at 2:16 AM, David Chisnall <David.Chisnall at cl.cam.ac.uk> wrote: > For our back end, we absolutely do not want a type system without pointers - not only do we have separate registers for pointers, we also have separate instructions for manipulating them and representing this in SelectionDAG requires some very ugly hacks. This is also the case for several DSPs, which

...d sealed by vendor, and > you have no way even to look inside, not to say re-shape interior to > your understanding [of security or anything else]. Am I the only one? Foolish and stupid implicit trust in a third party. Just look at the Windoze world ever since Win95 (first edition of many) materialised. Trust M$ and get a free virus every time ! I don't use my Android tablet after I discovered a default setting (semi-hidden away) was "Trust Google by automatically sharing all passwords with Google". I would like to use the tablet but only when there is a major free and entirely o...

Dear R users, I've just upgraded from R 0.64.1 to 1.1.0 on a PC running Red Hat Linux 6.0. When I ran demo(graphics), after the command: title(main = "January Pie Sales", cex.main = 1.8, font.main = 1) the plot did not materialise and I received this error message: Error in title(main = "January Pie Sales", cex.main = 1.8, font.main = 1) : X11 font at size 22 could not be loaded similarly, when I enter the following commands > testdata <- read.table("test.dat", header=T) > pairs(testdata) I...

On 14 June 2018 at 10:28, Tim Northover via llvm-dev <llvm-dev at lists.llvm.org> wrote: >> * I'd like to see ARM+AArch64+Hexagon move away from the problematic >> expansion in IR and to have that code deleted from AtomicExpandPass. Are >> there any objections? > > I think it would be a great shame and I'd like to avoid it if at all > possible, though