search for: materialisation

> 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. But the cost of doing that might be greater than the costs of keeping it in a register. Suppose the code was ORing a value with 5 and the target only had

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.

Hi, Sam. I think that it's a fair comparison. Keep in mind that the GP is only used to reach global variables of local scope and the GOT, where the address of global variables of global scope reside. This model assumes that the distance between the GP and the global data area, GOT and local scope variables is defined at link time. __ Evandro Menezes ◊ SiFive ◊ Austin, TX > On Mar

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

Hi Alasdair, > But the cost of doing that might be greater than the costs > of keeping it in a register. Suppose the 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

> 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

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

> 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.

On 2 Mar 2018, at 11:45, Nagaraju Mekala <nagaraju.mekala87 at gmail.com> wrote: > > yes they are dependent 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

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|

On 9 Aug 2013, at 22:15, Jakob Stoklund Olesen <stoklund at 2pi.dk> wrote: > I am a bit skeptical about the need for pointer types; I don’t think it is the right level of abstraction for an instruction selector. The processors I know about with separate address and data registers (Blackfin, m86k, TriCore) would be modeled perfectly by the register bank labels in the proposal. > >

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

On Aug 10, 2013, at 2:58 AM, David Chisnall <David.Chisnall at cl.cam.ac.uk> wrote: > On 9 Aug 2013, at 22:15, Jakob Stoklund Olesen <stoklund at 2pi.dk> wrote: > >> I am a bit skeptical about the need for pointer types; I don’t think it is the right level of abstraction for an instruction selector. The processors I know about with separate address and data registers

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

On Thu, 2015-02-05 at 09:27 -0600, Valeri Galtsev wrote: > .......... I feel like > there is brave new world of admins who feel it right to have > "iPad-like" everything, i.e. boxes cooked up and 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

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

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