| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
This patch makes sure that class destructors are called as they should
be when a C++ object allocated by ralloc is released.
Based on a previous patch by Kenneth Graunke, but it doesn't exhibit
the ~0.8% performance regression in shader compilation times because
we now use the HAS_TRIVIAL_DESTRUCTOR() macro to detect the typical
case where the indirect function call can be avoided because the
object's destructor doesn't need to do anything.
Reviewed-by: Ian Romanick <[email protected]>
|
| |
|
|
|
|
|
|
|
|
| |
Using it encourages the (IMHO worrying) practice of leaving member
variables uninitialized in constructor definitions. This macro
shouldn't be necessary anymore after the last patch series fixing all
its users to initialize all member variables from the class
constructor. Remove it.
Reviewed-by: Kenneth Graunke <[email protected]>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Most of our C++ classes define placement new and delete operators so we
can do convenient allocation via:
thing *foo = new(mem_ctx) thing(...)
Currently, this is done via a lot of boilerplate. By adding simple
macros to ralloc, we can condense this to a single line, making it
trivial to add this feature to a new class.
Signed-off-by: Kenneth Graunke <[email protected]>
Reviewed-by: Eric Anholt <[email protected]>
Reviewed-by: Chad Versace <[email protected]>
Reviewed-by: Ian Romanick <[email protected]>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Catches problems such as (in the gles3 branch)
glcpp-parse.y: In function '_glcpp_parser_handle_version_declaration':
glcpp-parse.y:1990:39: warning: format '%lli' expects argument of type
'long long int', but argument 4 has type 'int' [-Wformat]
As a side-effect, remove ralloc.c's likely/unlikely macros and just use
the ones from main/compiler.h.
NOTE: This is a candidate for the release branches.
Reviewed-by: Ian Romanick <[email protected]>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Both callers of rewrite_tail immediately compute the new total string
length by adding the (known) length of the existing string plus the
length of the newly appended text. Unfortunately, callers generally
won't know the length of the new text, as it's printf-formatted.
Since ralloc already computes this length, it makes sense to add it in
and save the caller the effort. This simplifies both existing callers,
but more importantly, will allow for cheap-appending in the next commit.
v2: The link_uniforms code needs both the old and new length.
Apply the obvious fix (which sadly makes it less of a cleanup).
Signed-off-by: Kenneth Graunke <[email protected]>
Reviewed-by: Ian Romanick <[email protected]> [v1]
Acked-by: José Fonseca <[email protected]> [v1]
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This can be useful if you want to create a bunch of temporary strings
with a common prefix. For example, when iterating over uniform
structure fields, one might want to create temporary strings like
"pallete.primary", "palette.outline", and "pallette.shadow".
This could be done by overwriting the '.' with a null-byte and calling
ralloc_asprintf_append, but that incurs the cost of strlen("pallete")
every time...when this is already known.
These new functions allow you rewrite the tail of the string, given a
starting index. If the starting index is the length of the string, this
is equivalent to appending.
Signed-off-by: Kenneth Graunke <[email protected]>
Reviewed-by: Ian Romanick <[email protected]>
|
| | |
|
| |
|
