[Mesa-dev] [PATCH 1/2] radeonsi: Cache LLVMTargetMachine object in si_screen

Tom Stellard tom at stellard.net
Fri Jan 16 06:41:02 PST 2015


On Wed, Jan 14, 2015 at 11:06:50AM +0900, Michel Dänzer wrote:
> On 14.01.2015 04:07, Tom Stellard wrote:
> > On Tue, Jan 13, 2015 at 06:47:00PM +0900, Michel Dänzer wrote:
> >> On 07.01.2015 10:10, Michel Dänzer wrote:
> >>> On 07.01.2015 06:33, Tom Stellard wrote:
> >>>> On Wed, Dec 24, 2014 at 12:48:31PM +0900, Michel Dänzer wrote:
> >>>>> On 24.12.2014 02:49, Tom Stellard wrote:
> >>>>>> Rather than building a new one every compile.  This should reduce some
> >>>>>> of the overhead of compiling shaders.
> >>>>>
> >>>>> Thanks, though unfortunately it doesn't seem to make much difference for
> >>>>> piglit for me.
> >>>>>
> >>>>>
> >>>>>> One consequence of this change is that we lose the MachineInstrs dumps
> >>>>>> when dumping the shaders via R600_DEBUG.  The LLVM IR and assembly is
> >>>>>> still dumped, and if you still want to see the MachineInstr dump, you
> >>>>>> can run the dumped LLVM IR through llc.
> >>>>>
> >>>>> Sounds reasonable, but...
> >>>>>
> >>>>>
> >>>>>> @@ -503,5 +510,12 @@ struct pipe_screen *radeonsi_screen_create(struct radeon_winsys *ws)
> >>>>>>  	/* Create the auxiliary context. This must be done last. */
> >>>>>>  	sscreen->b.aux_context = sscreen->b.b.context_create(&sscreen->b.b, NULL);
> >>>>>>  
> >>>>>> +	/* Initialize LLVM TargetMachine */
> >>>>>> +	r600_target = radeon_llvm_get_r600_target();
> >>>>>> +	sscreen->tm = LLVMCreateTargetMachine(r600_target, "r600--",
> >>>>>> +				r600_get_llvm_processor_name(sscreen->b.family),
> >>>>>> +				"+DumpCode", LLVMCodeGenLevelDefault, LLVMRelocDefault,
> >>>>>> +				LLVMCodeModelDefault);
> >>>>>> +
> >>>>>>  	return &sscreen->b.b;
> >>>>>>  }
> >>>>>
> >>>>> ... since you pass "+DumpCode" here, the MachineInstrs are actually
> >>>>> always dumped unconditionally. With that fixed, this patch is
> >>>>>
> >>>>
> >>>> I've removed the MF.dump() call in the LLVM tree, so this won't happen.
> >>>
> >>> That won't help people using LLVM 3.4 (or 3.5?), will it?
> >>
> >> Tom, users of LLVM 3.4/5 get spammed by MachineInstr dumps with this
> >> change, right? Do you have a plan to address this?
> >>
> > 
> > I disabled target machine caching for < LLVM 3.6, so this shouldn't be
> > an issue.
> 
> I see, thanks for the clarification.
> 
> BTW, do you think it would also be possible to keep around the LLVM
> module / context between shader compilations?
> 

We can cache the context.  We could cache the module too, but I'm not
sure if there are any advantages to doing that.

-Tom

> 
> -- 
> Earthling Michel Dänzer               |               http://www.amd.com
> Libre software enthusiast             |             Mesa and X developer


More information about the mesa-dev mailing list