| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
| |
I still wish I didn't have to force noinline just to avoid template functions
being more aggressively inlined.
|
| |
|
| |
|
|
|
|
| |
To avoid clashes with compilers that use it as a keyword already
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is very dumb. Template functions are implicitly marked inline according to
C++, and contrary to popular belief, "inline" *does* influence the compiler's
decision to inline a function. A function the compiler may not have decided to
inline normally may be inlined anyway, or issue a warning if it still decides
not to inline, if explicitly or implicitly marked as such (or does inline it as
requested, but then decides to not inline different functions it normally would
because of a cumulative code size increase or something).
Furthermore, once a function becomes inline due to being a template function,
there's no way to undo it. Marking an inline function "noinline" pushes the
problem the other way, causing the compiler to not inline a function it may
have decided was beneficial to inline. There's no way to declare a template
function to be inlined based solely on compiler heuristics, it will always be
influenced by the implicit "inline" or explicit "noinline".
That's what's happening here. A number of functions had been combined into a
smaller number of large-ish template functions to reduce code duplication and
ease maintanence, causing them to be implicitly inline as a side-effect. GCC
then manages to inline these larger functions as implicitly requested, but in
doing so prevents other smaller functions (which are explicitly marked inline)
from being inlined due to excessive code increase and issue a warning. The
"noinline" is a heavy-handed method of un-pessimizing the optimization pass, on
the assumption the compiler apparently doesn't actually want to inline the
template functions, but does so because they're technically marked inline.
There's no good option here until it gets acknowledged that inline does mean
something beyond allowing multiple definitions, and that template (and other
types of) function definitions sometimes (if not most often) want to allow
multiple definitions but don't want an artificial/detrimental boost in inline
prioritization.
/rant
|
| |
|
| |
|
|
|
|
|
| |
This provides better code locality when calling implicit context functions that
call their direct context variants.
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Only relevant for C++, but these functions can't throw as it's a C-based API.
Letting the compiler know that helps improve code generation. Extension
callbacks must also not let exceptions leave the callback, or else Bad Things
can happen.
The macro AL_DISABLE_NOEXCEPT may be defined before including the headers to
not mark functions as noexcept, but this should only be done if the caller
can't otherwise be fixed.
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
| |
All caller-usable formats are available as core formats now, so there's no
reason to distinguish between them.
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
To avoid alcProcessContext causing deferred EAX properties to be committed.
This simplifies updates when EAX has been initialized, but never or rarely
used.
Committing now always occurs in EAXSet when the property is non-deferred,
updating the OpenAL object(s) with it (with OpenAL's updates then being applied
based on the context's defer state).
|
| |
|
| |
|
|
|
|
|
|
| |
The AL_BUFFER query should only return the buffer that was set on a static
source, but some apps used it to detect when a current buffer of a streaming
source changed instead of AL_BUFFERS_PROCESSED.
|
|
|
|
|
| |
The syntax parser for GCC 8 (and earlier?) fails when these attributes are in
certain places.
|
| |
|
|
|
|
|
| |
Instead of recalculating it all the time, even for sources that don't use
callback buffers.
|
| |
|
|
|
|
|
|
|
|
|
| |
Presuming sources start in a neutral state for EAX effects, that is they're not
affected by EAX by default, there's no need to set an active EAX state for one
until the app sets an EAX property on it. Since the deferred and immediate
properties are stored independently per-version, they can always be set to
defaults, and simply not have a particular version committed as active until
the app sets an EAX property, which will inherently set the active version.
|
|
|
|
|
| |
A null effect slot can't be deleted, so we don't need to make sure it's set to
change before returning.
|
| |
|
| |
|
| |
|
| |
|