These ralloc contexts belong to a specific object and are being
deallocated manually from the class destructor. Now that we've hooked
up destructors to ralloc there's no reason for them to be children of
any other context, and doing so might to lead to double frees under
some circumstances. The class destructor has all the responsibility
of freeing class memory resources now.
void
cfg_t::create(void *parent_mem_ctx, exec_list *instructions)
{
- mem_ctx = ralloc_context(parent_mem_ctx);
+ mem_ctx = ralloc_context(NULL);
block_list.make_empty();
blocks = NULL;
num_blocks = 0;
fs_live_variables::fs_live_variables(fs_visitor *v, cfg_t *cfg)
: v(v), cfg(cfg)
{
- mem_ctx = this;
+ mem_ctx = ralloc_context(NULL);
num_vgrfs = v->virtual_grf_count;
num_vars = 0;
instruction_scheduler(backend_visitor *v, int grf_count, bool post_reg_alloc)
{
this->bv = v;
- this->mem_ctx = ralloc_context(v->mem_ctx);
+ this->mem_ctx = ralloc_context(NULL);
this->grf_count = grf_count;
this->instructions.make_empty();
this->instructions_to_schedule = 0;
vec4_live_variables::vec4_live_variables(vec4_visitor *v, cfg_t *cfg)
: v(v), cfg(cfg)
{
- mem_ctx = ralloc_context(cfg->mem_ctx);
+ mem_ctx = ralloc_context(NULL);
num_vars = v->virtual_grf_count * 4;
bd = rzalloc_array(mem_ctx, struct block_data, cfg->num_blocks);